NEW - Siglent X-Series Oscilloscopes and Arb Waveform Generators

[hendorog]

.NET might get there one day - at last Microsoft are getting off their high horse and talking about supporting other platforms, but its not a reality yet.

Not sure what you're talking about. .NET isn't Windows only, .Net programs can be made to run under Linux through Mono (OSS .Net clone), and Microsoft has now made relevant parts of the .Net framework open source anyways.

Mono has always been behind what is happening and has lacked the full support of MS. My observation is that it is seen as a poor cousin by .NET developers.
I agree that Microsoft are finally coming around and changing their policies, so hopefully mono will become mainstream with better support.
However it is hard to know what the current status is without actually using it as the devil is in the details.

Mac (btw, it's 'Mac' not 'MAC', the name of Apple's computers is not an acronym, and 'MAC' is something completely different than a computer made by Apple!) and Linux are pretty much niche platforms (Macs even more so than Linux) when it comes to T&M applications, fact is that Windows is by far the best supported platform and this is unlikely to change anytime soon.

Plus there's the problem that many (most?) cross platform programs often violate the style guides of at least one platform unless each variant gets an UI that is adapted to the target platform, which means a simple port won't cut it.

If Linux/Mac support is possible without compromising other variants then great but I'd primarily focus on the platform that roughly 95% of users are going to use.

Thats what got us into this mess... Chicken and egg situation. Many people use Apple products - I am typing this on an Apple laptop as it was by far the best hardware available for the price at the time. Linux is widely used in fields which are closely related to the electronics industry - e.g. education and software development. And of course in embedded systems.

The electronics and T&M market has become entrenched in Windows, which is frustrating for people used to using multiple platforms - the best platform for the job.

[tautech]

Steve from USA will see this and maybe get some optimisation done for other browsers and HW.

Well, they should have done that long ago, shouldn't they? I mean, there are exactly *three* main browsers (IE, Firefox, Chrome) and designing a website that works with all three isn't rocket science.

Plus what nbritton said, it's annoying and highly unprofessional. The website is the first face of your company most customers will see. Siglent.com is a mess, and very few visitors will be aware that they should go to siglentamerica.com (which is only partially better than siglent.com). Both websites clearly reflect the complete disregard for anything software in Siglent. Maybe it's not just the developers of EasyWave that are stuck in 1995?

I mean, seriously, if you can't even be arsed to get your website in order how can you expect people to see you as anything else than amateurs?

And you've taken the time to PM the CEO of Siglent America and mention website problems.........not. 

It would have taken less time than your post and you choose to pollute this thread with garbage. 

[Timur Born]

So if I was on the market for an Oscilloscope, would I get one of these inexpensive X-series Siglents, make use of their current price-drop on the SDS2000 range or rather look at other manufacturers in the price-range?

[tautech]

So if I was on the market for an Oscilloscope, would I get one of these inexpensive X-series Siglents, make use of their current price-drop on the SDS2000 range or rather look at other manufacturers in the price-range?

It really depends on your needs.

I've only had one for a day and basic functionality seems good and I need to spend more time with it.
At this time I like it very much, it is a nice entry level scope.

rf-loop says he has found several issues but as yet I don't know if they are serious or not.
I imagine that they can be remedied with firmware and hope Siglent fixes them fast.

[Timur Born]

It really depends on what it offers. 

Apart from the very useful 500 uV/div, what does the X series offer over other Oscilloscopes of its price-range?

And besides the higher sample-rate and memory-depth, what does the SDS2000 series offer over the X (with their price being closer together now)?

[rf-loop]

It really depends on what it offers. 

Apart from the very useful 500 uV/div, what does the X series offer over other Oscilloscopes of its price-range?

Up to amazing 500000 segment/s speed (measured top) acquire up to 1024 segments.. 
(in Siglent Ad sheet 300000/s what is more fair for more wide kind of situations)
Speed what is far over any scope what I know in this price class and next price class.  Many times speed is not so important due to typical use of segmented memory acquisition. But it need remember that if record example 10ns pulses every 1 second it can record 1000 fast pulses  and if there happend something what trig it come also captured, trigger rearm time is really short.
 If run this feature over amount of buffer (max 1024) it start new turn and overwrite old.  It takes while it can start new sequence.  Max repeating period with 1000 segments is somewhere around 80ms (I have measured only with some settings).  So it is not very useful to use it for continuous rare random glitches hunting from short trig period signal streams (as can see also in Dave's video. But there is lot of other things where this is very useful. 

Always when scope is running it also store every single acquisition with time stamp to history buffer using speed what is current wfm/s speed in use.  For this, there is up to 80000 acquisitions (depending one acquisition lenght)  FIFO  buffer. When ever stop scope, this buffer can inspect. Also these can horizontal pan/zoom and measure..

(it means: most simply example. You see something happend and you stop scope. Nearly always you are late...  but lets look history, you may find it still there (play back, forward, speed what you want). Of course if current wfm/s speed in use is 60000wfm/s there is only just over 1s hisstory.  You can also force scope to slow wfm/s speed. (if it is useful for example longer time history)

History buffer works seamless always in backround when scope is acquiring (exept if fast segmented memory acquisition is in use or scope is in roll mode) 

I do not know this level scope where ERES is used. More typical is boxcar average based Hi-Res function what need less processing and is not so good for signal details.

[Wuerstchenhund]

Mono has always been behind what is happening and has lacked the full support of MS.

Understandable, since Mono is not an MS project. In fact, MS had nothing o do with Mono, it was a project started by Ximian.

My observation is that it is seen as a poor cousin by .NET developers.

Then I have to say you didn't observe very well. Mono is not a cousin, it isn't even a MS project, it was created as a compatible clone of the .NET framework for non-Windows platforms (although Mono works on Windows as well). Of course since its a clone Mono isn't 100% compatible, and if you want to develop cross-platform there are a few things you need to pay attention to.

I agree that Microsoft are finally coming around and changing their policies, so hopefully mono will become mainstream with better support.

Mono *is* mainstream and very well supported on Linux and other non-Windows OSes (including Android), plus now that .Net is open source it will incorporate even more of parts of .Net which will make it even easier to write cross-platform applications.

However it is hard to know what the current status is without actually using it as the devil is in the details.

It's actually not that hard:

http://www.mono-project.com/docs/

But like with many other complex things you have to spend some time to become familiar with it.

If Linux/Mac support is possible without compromising other variants then great but I'd primarily focus on the platform that roughly 95% of users are going to use.

Thats what got us into this mess... Chicken and egg situation. Many people use Apple products - I am typing this on an Apple laptop as it was by far the best hardware available for the price at the time. Linux is widely used in fields which are closely related to the electronics industry - e.g. education and software development. And of course in embedded systems.

The electronics and T&M market has become entrenched in Windows, which is frustrating for people used to using multiple platforms - the best platform for the job.
[/quote]

As ntnico said the electronics market is mostly Windows and Linux, but yes, T&M is mostly Windows for good reasons, simply because most T&M engineers want to create test solutions quickly without fuss, and that is unfortunately easier than on Linux which generally needs a lot more babying.

Apple's OS X isn't an alternative simply because it's a desktop/laptop platform that runs of a very limited set of pretty expensive hardware, plus Apple's habit of cutting down on standard ports and the pretty short support cycles of OS and even hardware make it a pretty unattractive alternative for lab use.

Back to the idea of writing an open source waveform editor, you have two options here: you could use the idealistic way and develop for Linux or Mac as primary platform which I'm sure would make a few Linux and Mac users very happy, but then the vast majority of Siglent/Rigol AWG users will still have to rely on the crap Siglent and Rigol software because they run Windows. Or you can go the practical way and develop for the platform that is used by the majority of users (Windows), which means your software will serve a lot more people (plus you'll more likely to get useful feedback). And if you plan accordingly you can make your application cross-platform so Linux and even OS X isn't completely left out either.

[nctnico]

you could use the idealistic way and develop for Linux or Mac as primary platform which I'm sure would make a few Linux and Mac users very happy, but then the vast majority of Siglent/Rigol AWG users will still have to rely on the crap Siglent and Rigol software because they run Windows.

Sorry but this is just nonsense. Developers don't have to choose whether to develop cross platform or not. Nowadays it is actually easier to use a cross platform framework because such a framework comes with a lot of goodies which make programming easier regardless whether the goal is a cross platform application or not. Is that so hard to see? There is way more out there (and better too) than Visual Studio and .Net.

[hendorog]

Or you can go the practical way and develop for the platform that is used by the majority of users (Windows), which means your software will serve a lot more people (plus you'll more likely to get useful feedback). And if you plan accordingly you can make your application cross-platform so Linux and even OS X isn't completely left out either.

Exactly right. I recall that was where we started - sacrifice the bling if need be and make it cross platform.

[Wuerstchenhund]

Running .Net programs on Mac or Linux requires these programs have been designed to do so from the start. Microsoft isn't pushing that.

No, why should they? It's up to developers to take their target platform(s) into consideration.

Recents polls on EEVblog indicate about 30% of the people on this forum use Linux. I wouldn't call that a niche market for T&M and CAD software. The major vendors have been providing tools with support for multiple platforms for a good reason.

That's all nice and well but CAD (or software development or microcontroller toolkits or whatever) isn't T&M, you're comparing apples with oranges. And the fact is that T&M is predominantly Windows, which is the platform supported by all major T&M vendors. I agree that its sad (I'd like to see more Linux support), and it's slowly starting to change, but it would be illusory to believe Linux will be a relevant player in the T&M market in the next several years.

Last but not least: it is not difficult to write cross platform programs which are native applications when compiled for a certain platform (no, not emulated). There are excellent frameworks which do the heavy lifting and hide much of the idiosynchronies of the underlying OS (win-win). I'm writing Windows applications regulary but my primary test & development platform for those applications is Linux. When I hit compile on Linux I get a native Linux application and when I hit compile on Windows I get a native Windows application. In both cases the application will adhere to the user's style settings.

I'm not talking about native applications, I am talking about UX styleguides which are pretty different for Windows and Linux, and even more so for Apple OS X. It's all well and dandy if you compile your app as native executable for all platforms, but that doesn't miraculously change the user interface to Windows or OS X conventions. Which means you'd still have to design a separate UI for each platform, or you risk your app looking like cancer on other platforms.

[Wuerstchenhund]

Exactly right. I recall that was where we started - sacrifice the bling if need be and make it cross platform.

I agree except for the bling. The last thing you'd want is another app that looks like it came straight from 1995, something which seems to be the case for the majority of cross platform applications unfortunately.

The problem is that even most good software developers are pretty awful at UX design, which is very difficult to get right. And that unfortunately shows more often than not.

[hendorog]

Exactly right. I recall that was where we started - sacrifice the bling if need be and make it cross platform.

I agree except for the bling. The last thing you'd want is another app that looks like it came straight from 1995, something which seems to be the case for the majority of cross platform applications unfortunately.

The problem is that even most good software developers are pretty awful at UX design, which is very difficult to get right. And that unfortunately shows more often than not.

The rapid improvement in capability of browser based apps might make the OS irrelevant soon anyway. The old roadblocks which made that impractical that are rapidly going away. I used to think it would never happen, but now I'm not so sure.

[nctnico]

Last but not least: it is not difficult to write cross platform programs which are native applications when compiled for a certain platform (no, not emulated). There are excellent frameworks which do the heavy lifting and hide much of the idiosynchronies of the underlying OS (win-win). I'm writing Windows applications regulary but my primary test & development platform for those applications is Linux. When I hit compile on Linux I get a native Linux application and when I hit compile on Windows I get a native Windows application. In both cases the application will adhere to the user's style settings.

I'm not talking about native applications, I am talking about UX styleguides which are pretty different for Windows and Linux, and even more so for Apple OS X. It's all well and dandy if you compile your app as native executable for all platforms, but that doesn't miraculously change the user interface to Windows or OS X conventions. Which means you'd still have to design a separate UI for each platform, or you risk your app looking like cancer on other platforms.

That is overly dramatic. There are not many different ways to do a good user interface so OSX, Windows and Linux are not far apart nowadays. If you put applications for these platforms next to eachother you'll see they all have a border, they all have a menu, a status bar at the bottom and buttons & similar controls to do something and an area in the middle where stuff happens (show status, draw a graph, type text, etc). In a cross platform framework you typically just tell the framework 'I want these items in the menu and these buttons / controls at that location'. Because the framework uses the underlying OS's API to draw a window, buttons, etc the end result is a program which looks, feels and IS native to the target OS AND follows the user's preferences. You really don't have to design a different UI for each platform.

[nowlan]

IM a noob, but is python an option on linux, via lxi / scpi ?
Also do most test equipment come with LabView drivers?

[Wuerstchenhund]

That is overly dramatic.

No, it isn't, although I can certainly understand why you might think it is.

There are not many different ways to do a good user interface so OSX, Windows and Linux are not far apart nowadays. If you put applications for these platforms next to eachother you'll see they all have a border, they all have a menu, a status bar at the bottom and buttons & similar controls to do something and an area in the middle where stuff happens (show status, draw a graph, type text, etc). In a cross platform framework you typically just tell the framework 'I want these items in the menu and these buttons / controls at that location'. Because the framework uses the underlying OS's API to draw a window, buttons, etc the end result is a program which looks, feels and IS native to the target OS AND follows the user's preferences. You really don't have to design a different UI for each platform.

This is a very good example why I said most software developers are terrible at UX and UI design. There's a lot more to it than borders, menus etc. It's about how the application interacts with the the user in the various contexts on the platform, i.e. what are the users expectations and how are they satisfied by the program, the usability, integration in the environment and a lot more. It's for a reason why doing UX and UI design takes a lot of learning and experience, most of it (i.e. Human Factors) which is outside the scope of even most professional software developers.

Proper UI design also doesn't mean that you develop your app and slap some UI on top of it. The UI is a project in itself, i.e. several wireframes/sketches are produced, then when narrowed down mockups are created and evaluated in user trials, until the final design is found. And that is repeated for other platforms as well. Often developing the UI takes as much time or more than to develop the actual program behind it.

Don't take this personal but the fact you talk about APIs and frameworks for user elements tells me that you don't really fully understand UX or UI design. Which isn't surprising as I said many great software developers don't understand it, and which is why there are UX and HF specialists and UI designers and which is why they are often better paid than software developers.

BTW, one of the reasons why Apple is so successful is that they understand UX pretty well, much better than most other players in the market.

[nctnico]

Proper UI design also doesn't mean that you develop your app and slap some UI on top of it. The UI is a project in itself, i.e. several wireframes/sketches are produced, then when narrowed down mockups are created and evaluated in user trials

I'm not going as far as user trials (I leave that to my customers) but in the applications where I need a GUI the design of the GUI is a seperate (first) part of the project. Analysis of the workflow, what the user should do when, what the user perceives as logical, making sketches in Visio, making sure people with a visual handicap (color blindness for example) can use the program, etc are part of that. You can take UI design to all kinds of levels (and usually there isn't one best solution!) but when I sit behind a Mac, Windows or Linux machine I see the user interface design basics have moved together very closely. So unless you have a very specific user interface requirement (extremely dumb users, touch screen only, etc) there really is no reason to design a specific user interface for a specific platform. In many cases that would actually be counter productive. Take Eclipse or Kicad for example. If these applications would work differently depending on the OS it would be hard for users to switch from one OS to the other.

The point is: once the user interface design is done the user interface itself consists of controls which need to be placed somewhere inside a window and some code which deals with the user interface.

[znroot]

I just look the teardown... What about RTCC? Does the scope retain hour and data? 
And on Logic Analizer: the I2C, SPI etc they are publishing as product feature are only on the 2 channels, it's right?
Anyone know if there is the need to unlock the device through separate-buy serials?

[tautech]

I just look the teardown... What about RTCC? Does the scope retain hour and data? 
And on Logic Analizer: the I2C, SPI etc they are publishing as product feature are only on the 2 channels, it's right?
Anyone know if there is the need to unlock the device through separate-buy serials?

As for the RTC, at this stage it IS missing and a screen capture file date is very wrong.

As this is a new to market BUT pre-release dealer version there is quite probably more refinements of FW and HW to come.
The early SDS2000 series release to dealers did not have all HW installed.
Daves teardown shows this be the case also with the SDS1000X series as there are several unpopulated areas on the PCB.

Full option range and pricing at this stage has not been released.
There is a option management UI in the scope and it will be used when options and HW versions are offered.

Teardown link:
https://www.eevblog.com/forum/blog/eevblog-800-siglent-1000x-oscilloscope-teardown/

Edit
changed for better understanding,

[tautech]

SDG2042X review by Jack G. Ganssle:

http://www.embedded.com/electronics-blogs/break-points/4440636/Siglent-s-new-arbitrary-waveform-generator

[t3chiman]

Ordered a SDG2042X from Tequipment August 28; received October 23, 2015. A two-month wait. Bothersome on an "announced" product, but a definite improvement over the initial mid-December estimate. Product was packaged well and survived the UPS shipping ordeal in good shape cosmetically.

Initial bootup takes about 20 seconds. The screen is disconcertingly blank for the first 2 or 3, then lights up reassuringly. Initial versioning info:
S/W: 2.01.01.12R1
H/W: 01-00-00-22-00

A thread on the EEVBlog Specific board alerted me to the existence of a firmware update. I copied the SDG2000_V200R001B01D01P15R2.ADS  file to a 1GB USB flash drive, with partition type 0x0B ("Win95 FAT32") on a Suse Linux box. Actual firmware update proceeded according to the included Instructions. 30 seconds later, I got the "Restart" directive. New versioning info:
S/W: 2.01.01.15R2
H/W: 01-07-00-23-00  <<<<---- Interesting that the H/W version changed too.

Self-tests executed with no complaint.
On to the evaluation phase ...