EEVblog Electronics Community Forum

The Chinese press release dates back from January:
https://mp.weixin.qq.com/s?__biz=MzA3NDMwMzY3Mw==&mid=2650216528&idx=1&sn=b009e094f3442e64f9827c1204e68739

The oscilloscope is listed on the Chinese site from Siglent:
http://www.siglent.com/oscilloscope/SDS1000X-E%20Series

First tab: Technical summary
Second tab: User guide and data sheet
Third tab: Options
Fourth tab: Pricing in China for this model and other models

You can use Google Translate to translate the article about the Zynq-7000 SoC architecture.
However Google Translate seems to discard the pictures.

There also seems to be an SDS-1000X-C series.

What does the "C" stand for? China?

in the press released from xilinx cited in the other topic they talked about full memory decoding. does it mean it will decode on the full 14 MSps? (instead of only acquiring 1.4 MSps with decode on as it does now)

Quote from: EEVblog on March 28, 2017, 11:13:20 pm

There will not be a 70MHz, or 100MHz (the one I have), only a 200MHz version.
http://www.siglent.com/prodcut-db.aspx?id=1529&tid=1&T=2
And the 400k wfs update rate is marketing wank. That's in segmented mode.

You must have missed this:
Waveform capture rate of 100,000 frames / sec (normal mode); 400,000 frames per second (Sequence mode)
from this page:
http://www.siglent.com/oscilloscope/SDS1000X-E%20Series

That's what I said, segmented mode is sequence mode. They are pushing that number instead of the normal number.

in the press released from xilinx cited in the other topic they talked about full memory decoding. does it mean it will decode on the full 14 MSps? (instead of only acquiring 1.4 MSps with decode on as it does now)

Yes. Just same way as X/X+ but not rejected max 1.4M sample (because more brute force). And as we remember what ever is acquisition memory length it is equal with display width. (zoom for details).

Quote from: tautech on March 28, 2017, 11:28:19 pm

Quote from: EEVblog on March 28, 2017, 11:13:20 pm

There will not be a 70MHz, or 100MHz (the one I have), only a 200MHz version.
http://www.siglent.com/prodcut-db.aspx?id=1529&tid=1&T=2
And the 400k wfs update rate is marketing wank. That's in segmented mode.

You must have missed this:
Waveform capture rate of 100,000 frames / sec (normal mode); 400,000 frames per second (Sequence mode)
from this page:
http://www.siglent.com/oscilloscope/SDS1000X-E%20Series

That's what I said, segmented mode is sequence mode. They are pushing that number instead of the normal number.

Pushing and pushing...

In chinese side:

First :
Inside Product Overview text one sentence.

"waveform capture rates up to 400,000 frames per second (Sequence mode)"

And just after some sentences there read (without even scrolling page down, in same view, if just tiny eyes movement, under scope front image) very clearly:

"
Key Features:

* Bandwidth: 70MHz, 100MHz, 200MHz

* Real-time sampling rate of up to 1GSa / s

* New generation of SPO technology

    * Waveform capture rate of 100,000 frames per second (normal mode); 400,000 frames per second (Sequence mode)

    * Supports 256 levels of waveform brightness and color temperature display

    * Storage depth of 14Mpts

* Digital triggering system
"

What is pushed, what is wrong?

Perhaps this is too long and in western countries all need today be as instant messaging style. Sad.
But yes, some peoples can not be focused over 5 seconds. Overall this is going more and more bad when all is going to instant messaging.

Perhaps this is too long and in western countries all need today be as instant messaging style. Sad.

Is that you, Donald??
 

Any approx release date known yet?

Quote from: tautech on March 31, 2017, 06:16:54 pm

I'm told there's a fresh off the production line 200 MHz unit on the way to Dave right now. 

@Dave: please check the UART decoder thoroughly, at a fast baud rate (115200 or moar) and at 100ms/div or so (because a rigol 1000z can do that properly).

115K2 is hardly fast. I'd expect any decent serial decode to go to at least 4Mbaud, ideally more

115K2 is hardly fast. I'd expect any decent serial decode to go to at least 4Mbaud, ideally more

Of course the moar the better, but at low sweep speeds (100 ms/div) that's not possible, you'd need ~76MB mem depth/channel to decode @ 4Mbaud

Quote from: nctnico on March 31, 2017, 08:29:00 pm

I've seen scopes which go to 10Mbaud but on a regular UART this would require a clock speed of 160MHz. Maybe you could get away with 80MHz or 60MHz  on a UART with less clocks per bit but either way it is going beyond what you'd be 'normally' dealing with.

You don't need 16 clocks per bit. PIC32s can do 12.5Mbaud at 50MHz

Having only 4 clocks per bit will severely hamper the (digital) filtering and timing recovery a UART usually does. Why do you think a UART is typically designed to need 16 clocks per bit?

Quote from: mikeselectricstuff on March 31, 2017, 08:04:10 pm

115K2 is hardly fast. I'd expect any decent serial decode to go to at least 4Mbaud, ideally more

Of course the moar the better, but at low sweep speeds (100 ms/div) that's not possible, you'd need ~76MB mem depth/channel to decode @ 4Mbaud

there would be 40k characters per horizontal division. a scope is probably not the correct tool at this point

i also do know that the 1000x uart decode is limited to about 300 kbaud (too slow)
well, the current manual says 115200 but i may have read 300k somewhere else.

still, missed the point completely (even if we wanted to compare the siglent)

Quote from: JPortici on April 01, 2017, 05:03:42 am

Quote from: GeorgeOfTheJungle on March 31, 2017, 08:48:16 pm

Quote from: mikeselectricstuff on March 31, 2017, 08:04:10 pm

115K2 is hardly fast. I'd expect any decent serial decode to go to at least 4Mbaud, ideally more

Of course the moar the better, but at low sweep speeds (100 ms/div) that's not possible, you'd need ~76MB mem depth/channel to decode @ 4Mbaud

there would be 40k characters per horizontal division. a scope is probably not the correct tool at this point

You do know the SDS1kX series decode while in Zoom mode, of course you do you just forgot. 

@JPortici: That ^^^^^^ and there might be as well just a few tens of bytes (marks) scattered here and there (my use case):

"The other channel is sensing the current into the DUT, the code spits bytes at certain points to correlate execution with power input, the DUT is sleeping most of the time, only awakes every now and then and for less than ~2 seconds."

Thank you Dave. Where the X (not X-E) errs is when you do that at SLOW SWEEPS (10ms/div, 20ms/div or 50ms/div (*)) and then zoom in to see the data: you get mostly garbage at anything above 38.4Kbaud.

All about the bug is in this thread: https://www.eevblog.com/forum/testgear/siglent-sds1102x-serial-decoder-not-decoding-properly/

(*)In the latest fw updates they shut down the decoder @ 50ms/div or higher.

The red boxes in the video are decode errors

Quote from: mikeselectricstuff on March 31, 2017, 09:57:42 pm

you only need 3x clock to recover 100% good data from a clean stream.
Most UARTs have an option to do 8x to get higher baudrates, some have 4x.

Good to know, that would be great, but the SDS1000X seems to need not even 16 but hundreds to do it right, go figure.

Siglent officer told me that serial decoding, specially with some  low timebases is "broken" and this repair/improve  work is in "to-do list"
 
(This work is perhaps scheduled for "things to do" box. So, next coming FW update perhaps do not include this.) 

The software that Dave got is only a preview version from engineering, and hopefully the production software includes a proper implementation of hardware decoding. So I think we should not give up our hope already. We should not forget the reason why Siglent selected the Zynq-7000 SoC in the first place

In addition future software updates could also include support for the external trigger. Maybe Siglent just overlooked the external trigger capability. This is clearly a limitation in software for now, and not a hardware limitation.

Let's keep our fingers crossed on future software updates that include a proper implementation of hardware decoding and support for the external trigger! Good work so far Siglent!

Dave: Could you check if this scope also supports 9-bit data decoding?
I need this for a specific project that I am working on.

BTW: are the decoding errors really on purpose? I can't find that in the video.

Smells very much like some sort of April 1st prank me thinks

So is the SDS1202X-E going to be similar to the current 1202X but priced similarly (or cheaper than) the SDS1102X. Currently trying to decide between the Rigol DS1054Z, Keysight EDUX1002A and either the unreleased Siglent SDS1202X-E or SDS1102X. Serial decoding would definitely be nice so I'm tempted by the Rigol or Siglents (though the lack of an extra channel might be a pain), but I suppose I could always get a cheap logic analyser as well. The Rigol still looks like the best bang for the buck but the software and hardware on the Keysights and Siglents look to be slightly better.

Sorry for nitpicking, but please use the term "bps" (bits per second) when you're talking about the data rate. Seeing "Baud" on the scope's screen is . Baud is the symbol rate. A symbol can be the equivalent of muliple bits. Take QAM64 for example, a single symbol of QAM64 transports 6 bits. So a symbol rate of 1kbaud is a data rate of 6kbps.

In the context of UART data. Everyone uses baud. To use anything else would be confusing

The software that Dave got is only a preview version from engineering, and hopefully the production software includes a proper implementation of hardware decoding. So I think we should not give up our hope already. We should not forget the reason why Siglent selected the Zynq-7000 SoC in the first place

In addition future software updates could also include support for the external trigger. Maybe Siglent just overlooked the external trigger capability. This is clearly a limitation in software for now, and not a hardware limitation.

I admire your optimisim. 
Seems that Siglent haven't even come around to fixing serial decoding in the previous product:

Quote from: GeorgeOfTheJungle on April 01, 2017, 09:00:33 am

[...] the SDS1000X seems to need not even 16 but hundreds to do it right, go figure.

Siglent officer told me that serial decoding, specially with some  low timebases is "broken" and this repair/improve  work is in "to-do list"
(This work is perhaps scheduled for "things to do" box. So, next coming FW update perhaps do not include this.)

And no, I don't think that Siglent chose the Zynq chip primarily with hardware serial decoding in mind.
The Zynq is a cool chip, by the way, but I don't think it justifies developing a fixation... 

So is the SDS1202X-E going to be similar to the current 1202X but priced similarly (or cheaper than) the SDS1102X.

Yes.
X-E will have some features that are better than X models, but there will be some small differences too.
I see some small differences in the UI in Dave's vid.

Currently trying to decide between the Rigol DS1054Z, Keysight EDUX1002A and either the unreleased Siglent SDS1202X-E or SDS1102X. Serial decoding would definitely be nice so I'm tempted by the Rigol or Siglents (though the lack of an extra channel might be a pain), but I suppose I could always get a cheap logic analyser as well. The Rigol still looks like the best bang for the buck but the software and hardware on the Keysights and Siglents look to be slightly better.

X or X-E is the only choice if you want full BW 500uV inputs.
I don't know why Dave did the decoding at minimum memory depth, maybe just to show that it could. 

As the UI is very similar to existing models I would expect that bug count when released should be quite small.
A question to Tech support indicated they have some units at their beta testers and feedback is seeing a just few bugs reported. So we would expect a new FW release very soon after release addressing them as has happened with some of Siglent's other recent releases.

Quote from: pascal_sweden on April 01, 2017, 10:38:11 am

The software that Dave got is only a preview version from engineering, and hopefully the production software includes a proper implementation of hardware decoding. So I think we should not give up our hope already. We should not forget the reason why Siglent selected the Zynq-7000 SoC in the first place

In addition future software updates could also include support for the external trigger. Maybe Siglent just overlooked the external trigger capability. This is clearly a limitation in software for now, and not a hardware limitation.

I admire your optimisim. 
Seems that Siglent haven't even come around to fixing serial decoding in the previous product:

Quote from: rf-loop on April 01, 2017, 09:30:24 am

Quote from: GeorgeOfTheJungle on April 01, 2017, 09:00:33 am

[...] the SDS1000X seems to need not even 16 but hundreds to do it right, go figure.

Siglent officer told me that serial decoding, specially with some  low timebases is "broken" and this repair/improve  work is in "to-do list"
(This work is perhaps scheduled for "things to do" box. So, next coming FW update perhaps do not include this.)

And no, I don't think that Siglent chose the Zynq chip primarily with hardware serial decoding in mind.
The Zynq is a cool chip, by the way, but I don't think it justifies developing a fixation... 

Correct, but the Zynq chip offers some more grunt to implement some existing features better and possibly include more that can use the additional grunt.

Quote from: nctnico on April 01, 2017, 01:11:20 pm

If Siglent lives up to their reputation the SDS1202X-E will be riddled with bugs for the next 2 years so your best bet is the Rigol DS1000Z if you want decoding. I'd go for a 4 channel scope anyway because that is way more usefull than a 2 channel scope.

Um, no.  That would be making a decision based on speculation, and it's premature to do so.   No, his best bet is to wait for this new unit to come out and to see how well it actually holds up, and then make the decision.

Maybe it'll be riddled with bugs and maybe it won't be.  Siglent's history with longstanding bugs is mainly with respect to the SDS2000 series (not the 2000X or 1000X).  Put another way, it appears you're basing your criticism on how Siglent handled one model line, rather than multiple lines.   Which other lines had the same issue with longstanding bugs?  I know of none, but that doesn't mean they don't exist.  It's on you to point them out and to provide supporting evidence, since it's your claim that Siglent has a reputation for this.

Are you kidding? Look at the history of every product Siglent has released and you'll see it takes at least two years to iron out the serious bugs. Just look in the threads about Siglent power supplies, DMMs, signal generators or oscilloscopes and you can see for yourself. Maybe the SDS2000 is a low point in your mind but initially the SDG1000 series wasn't very useable with the original firmware (I ran the Lecroy firmware on mine for a long time) and it has a hardware issue as well, their new spectrum analyser had some issues with the tracking generator (current firmware sweeps much slower than before) and more recent someone found a serious problem in the UART decoding of the SDS1000X series scopes.

How does the beta tester structure look like? Are these based in both Europe and the USA?

Which credentials need to be fulfilled to become an official beta tester?

How does the beta tester structure look like? Are these based in both Europe and the USA?

Which credentials need to be fulfilled to become an official beta tester?

Only management will know who has X-E. There are beta testers worldwide.

Some EEVblog members are and have been beta testers for Siglent, but only those with demonstrated superior technical knowledge of the EE field. It is a very privileged position where secrecy is very important.
Users feedback is important too but without an existing relationship of trust and understanding users feedback need be detailed and clear so that engineers can simply replicate issues and seek remedies for the next firmware update.

Maybe Siglent should give a T-shirt to their official Beta testers!

That would help a lot with the secrecy requirement tautech had mentioned...

If you are a Beta tester for an unreleased scope model, you are bound to keep secrecy:
You can't reveal any details about an upcoming scope release and its technical specifications.

However, I don't believe it's an actual secret to know if you are a Beta tester or not.
Of course there could be an issue, if industry spies would find out and intercept your post packages

But why not introduce an official Beta tester statute to help testing products that are already released?
Then there is no secrecy about a new scope release or the technical specifications. And the community could help out in an official way to test out a new beta software version, using an official bug tracking system, such as JIRA, Bugzilla or ClearDDTS.

It looks to me like Siglent has substantially improved its responsiveness.

Sure there has been some improvement from Siglent but it depends greatly on how much focus there is on a product (look at their handheld scopes for example https://www.eevblog.com/forum/testgear/siglent-technical-support-join-in-eevblog/msg1172051/#msg1172051). Siglent also keeps missing silly bugs that other manufacturers catch early by doing proper software testing. Anyway, financially it doesn't make sense to me to do a full functional test on every piece of equipment I buy. I'm better off paying a bit more (and/or buy a used A-brand) so I can trust a piece of equipment just works as specified.

Good catch about the missing LA slot!

Weird placement of the USB connector and there is no indented section around the power button like there is in the SDS1000X series.

Actually the SDS1000X-E series does not use the same case as the SDS1000X series.
Maybe it will in the final production version?

Could this be a pre-production case?

Good catch about the missing LA slot!

Weird placement of the USB connector and there is no indented section around the power button like there is in the SDS1000X series.

Actually the SDS1000X-E series does not use the same case as the SDS1000X series.
Maybe it will in the final production version?

Could this be a pre-production case?

WYSIWYG

X-E display is 7" and X/X+ 8" same 800x480 resolution.

The X-E's display is smaller than the X's ? One inch smaller? Really? Are you sure? If so, that for me is a "thumbs down". Grrrr.

Quote from: pascal_sweden on April 01, 2017, 09:05:22 pm

How does the beta tester structure look like? Are these based in both Europe and the USA?

Which credentials need to be fulfilled to become an official beta tester?

Only management will know who has X-E. There are beta testers worldwide.

The SDS1kX was a pleasure to work with, very responsive and the display clear and big. I would happily beta-test the X-E.

Quote from: rf-loop on April 02, 2017, 06:03:50 am

SDS1202X-Economy  do not have internal HW for MSO feature and because this, also no need LA connector.
If need MSO, then select bigger X+ model with 16Ch LA (+ also 25MHz signal generator)

As tautech told WYSIWYG.

Will the SDS1000X-E have a plus version as well? (including la and signal gen)?

What's so hard to understand about rf-loop's statement?

No, for the time being, Siglent wants you to buy the more expensive models if you need that extra functionality. It's called market segmentation. They might eventually follow up with an X-E plus version, if competitive pressure forces them to do so. But they will not tell you now, because -- as mentioned before -- they want you to buy the X+.

Quote from: nctnico on April 02, 2017, 12:06:06 am

Sure there has been some improvement from Siglent but it depends greatly on how much focus there is on a product

Yes, but here, "focus on a product" is directly related (though not solely related) to the sales of the product, which will in turn determine the probability that any given bug will be found.  Of course, the focus isn't determined solely by that.  I suspect the SDS2000X series did substantially better than the SDS2000 series in large part because of the beating Siglent took due to their handling of the latter.

Sorry but your assumption users should find bugs makes my jaws drop to the floor. Ideally a product should not be shipped with bugs but that is ideally. However with good test procedures in place a piece of test equipment should not have the silly bugs Rigol and Siglent are famous for. That is the major difference between the low end brands and the more expensive brands.

Regarding the SDS2000(X): AFAIK: the high-resolution mode is still limited to 1.4kpts so pretty much useless. I use high-res/filtering often to remove noise in order to make the actual signal more clear but with only 1.4kpts to look at you can only see a short part of a signal. And there are more ass-backward things Siglent does like shortening the memory length automatically. I don't recall any other DSO doing something like that. Either use the full memory length or use the length the user has selected.

In fact, the very scope you settled on had issues by your very own admission.  What's the difference between your experience with it versus your experience with Siglent?   Clearly, the main difference is the speed with which Instek fixed the issues you reported to them.   You came away impressed by that, and rightly so. 

The difference is that:
1) the bugs I found in the GDS-2000E where rather obscure, there where only two and both got fixed within weeks
2) overall the GDS-2000E firmware is way more mature with many tiny details which make life easier.
I really dug deep into the GDS-2000E to hunt for bugs: https://www.eevblog.com/forum/testgear/gw-instek-gds2204e-(200mhz-4-channel-dso)-review/

BTW: you asked about problems in the SDG1000(X) and SDG2000X signal generators. There is at least one: the log sweep doesn't work. Instead of sweeping the generator produces a series of frequency steps. Not nice when testing a notch filter.

Also when I use my SDG1010 I notice I don't trust it at all. It has been through so many firmware versions each with their own quirks that I'm totally lost on what works and what doesn't. When I need to test something quick I use my cheap Feeltech FY3200 generator and I'm thinking about getting a different/new signal generator from a higher end brand.

Quote from: kcbrown on April 02, 2017, 01:00:04 am

Quote from: nctnico on April 02, 2017, 12:06:06 am

Sure there has been some improvement from Siglent but it depends greatly on how much focus there is on a product

Yes, but here, "focus on a product" is directly related (though not solely related) to the sales of the product, which will in turn determine the probability that any given bug will be found.  Of course, the focus isn't determined solely by that.  I suspect the SDS2000X series did substantially better than the SDS2000 series in large part because of the beating Siglent took due to their handling of the latter.

Sorry but your assumption users should find bugs makes my jaws drop to the floor.

My "assumption", which is really just an observation of reality, is that users will find bugs that the vendor does not, and that the probability that a given bug will be found by a user is going to increase with the number of users who are using the product.  The probability that a bug will be found is the probability that the vendor will find the bug combined with the probability that a user will find the bug.  The former is probably close to a constant for a given vendor, which makes the latter the only variable in the equation.

Of course the vendor should be attempting to find bugs themselves.  But the reality is that they won't find them all, no matter how hard they try, and the harder they try, the more expensive the product will be and the longer the time to market.

Ideally a product should not be shipped with bugs but that is ideally. However with good test procedures in place a piece of test equipment should not have the silly bugs Rigol and Siglent are famous for. That is the major difference between the low end brands and the more expensive brands.

You mean silly bugs like persistence not working?

Regarding the SDS2000(X): AFAIK: the high-resolution mode is still limited to 1.4kpts so pretty much useless.

How do you know that's a bug and not a straight-up limitation of the architecture?   Admittedly, it's quite the limitation.  But the GDS2204E doesn't have high-resolution mode at all (unless something's changed since you produced your review), so how is the SDS2000X worse in that regard?

I use high-res/filtering often to remove noise in order to make the actual signal more clear but with only 1.4kpts to look at you can only see a short part of a signal. And there are more ass-backward things Siglent does like shortening the memory length automatically. I don't recall any other DSO doing something like that. Either use the full memory length or use the length the user has selected.

I thought the Siglent used the memory length the user selected and then set the acquisition rate based on the window of time shown on the display, since they're using the "what you see is all you get" approach to acquisition.   No?

The difference is that:
1) the bugs I found in the GDS-2000E where rather obscure, there where only two and both got fixed within weeks

What was "obscure" about persistence not working?   Admittedly, you didn't elaborate on what was wrong with it in your (quite nice) writeup.

2) overall the GDS-2000E firmware is way more mature with many tiny details which make life easier.
I really dug deep into the GDS-2000E to hunt for bugs: https://www.eevblog.com/forum/testgear/gw-instek-gds2204e-(200mhz-4-channel-dso)-review/

Right, but the same can't be said of their prior GDS-2104 (https://www.eevblog.com/forum/testgear/opinions-on-gw-instek-scopes/msg1131212/#msg1131212), can it?

Instek has apparently improved quite a lot in that department.   I suspect much of that is because Instek re-used the code from the firmware in their prior models, so the bugfixes that went into those prior models also made it into their newer models, and it shows.

Why should we believe that Siglent will do anything different in that regard, particularly with the SDS1000X-E?

BTW: you asked about problems in the SDG1000(X) and SDG2000X signal generators. There is at least one: the log sweep doesn't work. Instead of sweeping the generator produces a series of frequency steps. Not nice when testing a notch filter.

It's not clear to me how that can be entirely avoided in a digital instrument like this, though there are certainly going to be ways to minimize the effect (e.g., for sweeps, keeping the interval between frequency changes very short, like 1ms or something, and performing the frequency step calculation on the fly).  I noticed that the steps are apparent at low frequencies but not so much at higher ones (I suspect it would be a lot more apparent with a proper and fast FFT, so your Instek scope would be excellent for showing it), as if it's computing a fixed-size series of frequencies to use with some sort of integer value as its basis, and it's just running the value through a log-based function to arrive at the desired frequency.    Yes, that won't work very well for testing a notch filter, though it looks to me like it may be generating a fixed number of frequencies to use, so at least it looks like you can increase the frequency resolution by narrowing the frequency range.

Do you see the same effect when using linear sweep?

This particular behavior smells like a design flaw to me more than a garden variety bug, but perhaps a rewrite of the log sweep engine could take care of it.


Why in the world didn't you stick with the LeCroy firmware?   It's LeCroy.  Surely it doesn't have any glaring faults like this, since it's from an A-brand manufacturer ... right?

Also when I use my SDG1010 I notice I don't trust it at all. It has been through so many firmware versions each with their own quirks that I'm totally lost on what works and what doesn't. When I need to test something quick I use my cheap Feeltech FY3200 generator and I'm thinking about getting a different/new signal generator from a higher end brand.

You definitely should get a different waveform generator in that case.  You have to be able to trust your equipment.  That trust ultimately has to come from experience, but as you say (and I agree), the A-brands are going to at least start from a better point.  Looks like Instek has a decent range of waveform generators.  Given your positive experience with them, I don't think I'd hesitate to go for one of their units as long as the specs meet your requirements.   Something "equivalent" from Keysight will cost you at least 1.5x what the Instek units would, from what I'm seeing.

While I think you overstate things with respect to Siglent's newer offerings ("riddled with bugs"), I do think there's a kernel of truth in what you say: the upper-tier brands will generally (not always, but then, there's exceptions to everything) do better in terms of releasing stable and functional products.   You do pay quite a lot more for it, though.  There ain't no such thing as a free lunch.   There's a reason the "B-brand" manufacturers are able to hit substantially lower pricepoints.  Good QC is expensive.  If brands like Siglent were to adopt the QC methods of the "A-brand" manufacturers, how exactly would you expect them to hit their current price targets?   "B-brand" manufacturers can do things to minimize both development costs and QC costs like reusing firmware from previous models, and I fully expect that's what Siglent is doing here (which is why I'm skeptical of the claim that the 1000X-E will be "riddled with bugs"), but that's very different from adopting the QC methods in use by the "A-brand" manufacturers.

Quote from: kcbrown on April 02, 2017, 08:02:03 pm

Quote from: nctnico on April 02, 2017, 11:30:41 am

The difference is that:
1) the bugs I found in the GDS-2000E where rather obscure, there where only two and both got fixed within weeks

What was "obscure" about persistence not working?   Admittedly, you didn't elaborate on what was wrong with it in your (quite nice) writeup.

It was quite hard to spot but IIRC there was no difference between selecting 16ms and 500ms or something like that.

Oh, interesting.  Please alter your writeup and put that in it.  That kind of thing is useful to demonstrate that the bug in the feature in question isn't a fundamental one.

Quote

Right, but the same can't be said of their prior GDS-2104 (https://www.eevblog.com/forum/testgear/opinions-on-gw-instek-scopes/msg1131212/#msg1131212), can it?

After reading the thread again IMHO it is a bit of a grey area on where to put the blame.

How so?  The user who had the problem said that they'd been waiting for Instek to fix the problems for years and finally just gave up on it.

Appearantly there was new firmware available for this (now obsolete) scope but the owners never looked/asked for a new version. I can't believe a new firmware version is released just before a piece of equipment is taken out of production so it must have been available for a longer period.

True, but we can't know how much time transpired between when the user in question bought his scope and the point in time that Instek finally released an updated version.   That user had been checking for updates for some time, apparently, without any success.

You might want to have a look at their firmware page for that scope.  They released another version 2 weeks ago.   That's very good support considering it's a discontinued product, but it raises the possibility (remote though it might be) that it wasn't until they discontinued the product that they started issuing new releases for that particular product.   Indeed, it might be that they're releasing new versions of the firmware for that scope because they're fixing bugs in their current products, and those fixes are being backmerged into the old product's firmware.   If they're doing that, then it really is excellent product support, because they certainly don't have to do that at all.

Their firmware releases don't seem to include a changelog, however, something that even Rigol manages to include, so Instek still has some improving to do here.


In any case, the point here is that Instek apparently has not always been the responsive company your experiences indicate it to be.  They've improved.   If they can improve, what says Siglent can't and, more importantly, what says they haven't?

Unfortunately GW Instek is a bit daft when it comes to publishing firmware on their website. They rather send it when people ask for it (see the obsolete GW Instek DMMs currently on sale on Ebay).

That is odd.  But perhaps they're improving on that front as well.   Here's hoping, anyway ...

Quote

This particular behavior smells like a design flaw to me more than a garden variety bug, but perhaps a rewrite of the log sweep engine could take care of it.

Bug or design flaw doesn't matter: it doesn't work.

Wait.   What exactly do you mean by it doesn't work here?   It performs a "sweep", but it's not "smooth" at lower frequencies when there's more than 2 orders of magnitude between the lowest frequency and the highest one.   Any smoothness that one perceives is likely to be perception only -- chances are it's stepping through a set of frequencies regardless, and I'd wager it's doing that even in linear sweep mode.

What exactly are your expectations here?  That the frequency sweep be truly continuous?



It would be really interesting to characterize the log sweep of an A-brand AWG like the one from Keysight.

I agree it could be interesting to look at the log sweep output with a spectrum analyser or FFT but what is the purpose?

The purpose would be to better characterize the bug.  That kind of thing can help the development team track down the root cause quite a lot.  In this case, because the issue is reproducible at will, it probably doesn't matter a whole lot.

Linear sweep works fine BTW.

Interesting.  But in light of the above, are you sure?

What's the advantage, for testing, of using log sweep versus linear sweep?

Chinese brands can deploy cheap labour for testing and programming. That is where they get their advantage from when it comes to price. Doing a full functional test is a really simple job that doesn't take much education so doesn't need to cost much.

So can the traditional manufacturers.  If it were just about that, then I'd expect the traditional manufacturers to already be doing this in order to (substantially) reduce their costs.

The root cause however is not saving money but incompetence when it comes to managing software development. I have some experience with Chinese software developers myself and it made me want to cry. Every concept of creating quality software and testing was completely alien to them and their bugs reminded me of the ones Siglent and Rigol show. The good Chinese software developers all seem to work in the US and Europe.

I certainly can't dispute that.   But if that's truly the case, then explain GW Instek.   Their developers aren't in the U.S. or Europe, are they?

And in any case, we saw a similar pattern with hardware.   The Chinese initially had a reputation for producing junk hardware.  Today, they're perfectly capable of producing hardware of quite good quality.   And we've seen improvements on the software front as well.   Like it or not, the initial incident rate of bugs seems to be lower now than it was before, and the speed with which bugs are fixed seems to have improved as well.

The Chinese seem to be learning, just like the Japanese before them (the Japanese seem to have a culture of meticulousness that the Chinese lack, however, so the Chinese might not improve as fast as the Japanese did).

There's a reason the "B-brand" manufacturers are able to hit substantially lower pricepoints.  Good QC is expensive.  If brands like Siglent were to adopt the QC methods of the "A-brand" manufacturers, how exactly would you expect them to hit their current price targets? 

Another major factor in hitting those price points is reverse engineering the pioneering efforts in the A-brands' products. Big R&D savings there. 

Anybody found the SDS 1202X-E available for sale in the US?

I would certainly like to see a review; Dave's tear-down was impressive.  This scope, other than channels, could unseat the DS1054Z as THE entry level scope.  200 MHz, free decoding, large screen, less than $400, what's not to like?

Anybody found the SDS 1202X-E available for sale in the US?

I would certainly like to see a review; Dave's tear-down was impressive.  This scope, other than channels, could unseat the DS1054Z as THE entry level scope.  200 MHz, free decoding, large screen, less than $400, what's not to like?

Personally I do not like this: Not large screen. It is 7" 800x480
But my eyes are old.

Personally I do not like this: Not large screen. It is 7" 800x480

Neither do I, it's a step back.

I was thinking the same thing.
WVGA 800x480 is pretty much standard even on higher end scopes. There are some with 8" screens but the resolution is the same. Not really that a big of an issue.
I could only think of the Micsigs that have 8" 800x600, but they are completely different animals.

+1 for small screen
let's see the price first... if it'll be cheap as they say i think many won't care that it has a small screen

Quote from: coppice on April 06, 2017, 07:55:55 am

Which entry level scope with a larger screen than 7" or a higher resolution than 800x480 is this a step back from?

The SDS1kX (not -E)

That's a more expensive machine. I know lots of more expensive machines with better features.

What $400 scope has a better screen?

It makes some sense if you have eyesight issues.

I do...

But if you do not, then you just get bigger pixels and less sharpness.

By that rule 3" would be even better, a "retina display scope" huh!

BTW, all the rigols have the same screen resolution, but the 1000z's are 7", 2000's are 8", 4000's are 9" and 6000's are 10", JFYI :-)

Quote from: coppice on April 06, 2017, 10:56:32 am

What $400 scope has a better screen?

SDS-1102X    -> 396€ + taxes
SDS-1202X-E -> 359€ + taxes

SDS1102X is Euro 475 now discounted at Euro 403,75 (+ taxes)
This promo will end on July the 1st so the difference will be pretty big

Everything else looks like a step forward though

Seeing Dave's video I'm not so sure, it doesn't decode (*) any faster (have you seen a keysight decoding? that's fast!) and the UI seems to be ~ as responsive as the 1000X, not any better afaics. The screen is smaller and 99.9999% of the time I don't need the extra bandwidth.

(*) Too bad Dave doesn't even try to see if the 1000X's serial decoder bug is there too in the X-Es.

True

Although Keysights cost almost double the money so not really a fair comparison.

I do not really care for that stuff much either. I just feel that it's time to upgrade my 1052.

I am more interested to see the implementation of features like low/pass/band pass filters and FFT

Siglent says FFT has 1 Mpts, very curious to test it 

with 2 GS/s (per chan?). Still if it was 2GS/s shared you'd see a difference in waveform stability when looking at fast signals. Keysight is not in the same instrument class

That has a 7" screen. Wouldn't you consider it a huge step backwards?

Sure, I would, if the previous generation had come with 8", yes.

Siglent says FFT has 1 Mpts, very curious to test it 

Interesting can FFT sample rate be altered (up to 1G)? Multiple traces?
In this example I presume 100MSa/s => max 50MHz / 95Hz => 500k FFT bins. So not sure which is correct to call it 1M or 500k FFT? Until now I considered FFT "1M" if it has 1M bins (2M points).
BTW is FFT always limited to 0...XHz + "zoom window" analysis in scopes or some advanced ones allow make actual window like on real SAs? This would make having millions of points much less important. Theoretically should be possible... ?

There was a new separate thread created for the SDS1202X-E oscilloscope yesterday.

Maybe it is better to keep everything under this thread, as this thread was the first thread related to this new oscilloscope from Siglent.

I did this table, sorry for the format ... 
It may bring some more info

	SDS1202X-E	EDUX1002A
Bandwidth	200MHz	50MHz
Analog Channels	2	2
Max Real Time Sampling Rate	1GSa/sec	1GSa/sec
Max Memory Depth	14Mpts	100Kpts
FFT	1Mpts	64Kpts
Waveform Capture rate in normal mode	100.000	50.000
Waveform Capture rate in sequence mode	400.000	NO
Serial Trigger and Decode	I²C, SPI, UART/RS232, CAN, LIN (Standard)	I²C, UART/RS232 (Optional)
256-level intensity grading and color temperature display	yes	Only 256-level intensity grading
Vertical Sensitivity	500 uV ~ 10 V	1 mV ~ 10 V 500 uV (20MHz limited)
Timebase	1 ns ~ 100 s	5 ns ~ 50 s
Sequence function	Support, minimum dead time low to 2.5 ?s	NO
History function	Support,  maximum of 80,000 frames can be recorded	NO
Enhanced / high resolution mode	YES	YES
Trigger type	Edge , slope, pulse width, window , Runt, Interval, Dropout, Pattern , video (support HDTV)	Edge, pulse width, video (NTSC, PAL, SECAM and PAM-M), rise/fall time, setup and hold, pattern/state
Auto measurement and statistics	Support 38 Types, 6 Types statistics info: value, mean, min, max, stev, num	Support 28 Types
Pass/Fail (Mask Test)	YES	NO
Interface	USB Host & Device,LAN,AUX (Pass/Fail,Trigger Out)	USB Host & Device
Display	7 inch (800*480), 8*14 grid display	7 inch WVGA, 8*10 grid display
Price	EURO 359 USD 379	EURO 414 USD 448

Quote from: GeorgeOfTheJungle on April 06, 2017, 02:28:39 pm

Even the EDUX1000s' decoders fly, but yes that's ~ $448+$150 kopecks (+taxes?), a bit moar than a Siglent.

And 50 vs. 200 MHz bandwidth, right?
If "fast decoders" vs. "4x the bandwidth" would be the only difference, I'm pretty sure I would opt for the Siglent, even if prices were the same...

Let's see about that when the first in depth reviews are in. IMHO competing on price instead of quality is a sign of desperation. I think the market for low cost, low quality scopes has been pretty much saturated by the Rigol DS1054Z anyway. It seems there is a lot of interest in scopes which can do more and have fewer (no) bugs. See how many people jumped onto the R&S RTB2004 special offer even though it costs over US $2k.

Let's see about that when the first in depth reviews are in. IMHO competing on price instead of quality is a sign of desperation. I think the market for low cost, low quality scopes has been pretty much saturated by the Rigol DS1054Z anyway. It seems there is a lot of interest in scopes which can do more and have fewer (no) bugs. See how many people jumped onto the R&S RTB2004 special offer even though it costs over US $2k.

That! ^^^^+1

Quote from: ebastler on April 06, 2017, 05:29:26 pm

And 50 vs. 200 MHz bandwidth, right?
If "fast decoders" vs. "4x the bandwidth" would be the only difference, I'm pretty sure I would opt for the Siglent, even if prices were the same...

Let's see about that when the first in depth reviews are in. IMHO competing on price instead of quality is a sign of desperation. I think the market for low cost, low quality scopes has been pretty much saturated by the Rigol DS1054Z anyway. It seems there is a lot of interest in scopes which can do more and have fewer (no) bugs. See how many people jumped onto the R&S RTB2004 special offer even though it costs over US $2k.

Please note that I did say that the Siglent looks good not on a "competing by price" basis, but has a significant performance advantage over the Keysight (namely bandwidth). I agree with you there, to the extent that the price/performance ratio, and the level of performance and quality one needs, should drive the purchase decision; certainly not price alone.

On the other hand, the "bugs" topic is vastly inflated by a few users here. (Yes, I know, GW Instek rules...) And I believe that people bought the R&S because the promo deal looked like an offer you can't refuse, if you happen to be in the market for a scope. Let's see how many people value the R&S quality (nice screen, nice knobs and all) at the regular price, or where the market price eventually settles.

On the other hand, the "bugs" topic is vastly inflated by a few users here.

The sds1kx serial decoder bug is very real and a show stopper for me. It's great to buy cheapo if it ~ works better or worse as the 1000z (sluggish, but does the job), but not so great if it doesn't at all as that siglent. I've had to return it even though I still like it very much, fast responsive and a gorgeous display, but sadly not what I was looking for as it can't decode properly.

they claim its a 1MP fft which it is. they never claimed that it is an 1M bins fft

Claim is indeed correct, that means my scope has 2MP FFT, despite being speced as 1MP
But they also list 1GSa/s scopes on Farnell as 250MSa/s so indeed, why not downgrade FFT spec as well

FYI:
https://www.eevblog.com/forum/testgear/new-siglent-sds1000x-e-oscilloscope-based-on-xilinx-zynq-7000-soc-architecture/msg1180403/#msg1180403

view/download PDF data sheet
http://www.batterfly.com/PDF/Siglent/siglent-sds1202xe-datasheet.pdf

view/download PDF user manual
http://www.batterfly.com/PDF/Siglent/SDS1000X-E_UserManul_UM0101E-E02A.pdf

Quote from: rf-loop on April 07, 2017, 07:06:09 am

Here data sheet pdf until downloadable from Siglent web side.

Thanks. Not sure whether this has been discussed before: How does the scope handle SPI decoding (SCL, MISO, MOSI, CS) with just two inputs?

i would assume scl + miso (or mosi) + timeout
unless in the meantime they added the third digital channel

view/download PDF data sheet
http://www.batterfly.com/PDF/Siglent/siglent-sds1202xe-datasheet.pdf

see that UART trigger is 334000 bps max! okay, trigger.. one can get around it
no mention for uart decode max baud rate

besides SPI have a good look at the uart decode, if it can decode 115200 reliably and how high can it be

Quote from: rf-loop on April 07, 2017, 07:06:09 am

Here data sheet pdf until downloadable from Siglent web side.

There is an error near the end, Optional Accessories should start at where the last Standard accessory CD is listed.

We also noticed that, but when looking better there is a very thin line which divides standard form optionals

Yes it need bit clarify.