Author Topic: At last, Siglent's SDS5054X touchscreen DSO...  (Read 23015 times)

0 Members and 1 Guest are viewing this topic.

Online 0xdeadbeef

  • Super Contributor
  • ***
  • Posts: 1315
  • Country: de
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #125 on: February 05, 2019, 07:40:54 pm »
Interesting though that the SDSX5000 datasheet states a minimum (!) dead time of 2µs.
In contrast to this, the 200ns given for the RTM3K is the maximum value. So actually comparing both value doesn't make much sense anyway. or not.
IMHO Siglent probably got minimum and maximum confused. It doesn't make sense to specify minimum dead time. Maybe they reasoned the smallest guaranteed dead time is 2us and thought they should put that under minimum because it is the smallest (which is wrong ofcourse).
I would tend to agree, but they state it as minimum twice in the data sheet.
1) "The dead time between segments can be as small as 2 μs."
2) "dead time = 2 μs min"
Trying is the first step towards failure - Homer J. Simpson
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 17660
  • Country: nl
    • NCT Developments
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #126 on: February 05, 2019, 07:46:28 pm »
I'm pretty sure Siglent got minimum and maximum confused.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online 2N3055

  • Super Contributor
  • ***
  • Posts: 2087
  • Country: hr
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #127 on: February 05, 2019, 07:56:55 pm »
Specification  for SDS5000X says:

Waveform Capture Rate (Max.)
110,000 wfm/s (normal mode),480,000 wfm/s (sequence mode)
that is slightly over 2 us between segments.
 

Online 0xdeadbeef

  • Super Contributor
  • ***
  • Posts: 1315
  • Country: de
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #128 on: February 05, 2019, 07:57:54 pm »
I'm pretty sure Siglent got minimum and maximum confused.
I hope you're right, but then they also got "small" and "big" confused. So these guys must be rather confused.
Trying is the first step towards failure - Homer J. Simpson
 

Offline Performa01

  • Frequent Contributor
  • **
  • Posts: 817
  • Country: at
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #129 on: February 08, 2019, 11:53:27 pm »
I'm pretty sure Siglent got minimum and maximum confused.
I hope you're right, but then they also got "small" and "big" confused. So these guys must be rather confused.
Well, perhaps the folks at Keysight are confused too (quote from DSOX3000T datasheet):
Quote
Segmented memory optimizes available memory for data streams that have long dead times between activity. Maximum segments = 1000. Re-arm time = 1 μs (minimum time between trigger events)

I have double checked sequence recording with the latest firmware and found the minimum re-arm time to be slightly improved to <1.4µs.

The maximum waveform update rate in sequence mode was originally specified as 500kwfm/s but I had to request a down-rating to 480kwfm/s (as in the current datasheet) because I could not get more than some 490kwfm/s maximum with an early firmware. Now I’m glad to see the original spec is met with the most recent firmware at >517kwfm/s.

The maximum number of segments is 100.000, as specified.

BTW, the R&S RTM3000 with RTM-K15 option does not offer more total acquisition memory than the Siglent SDS5000X:

Siglent SDS5000X provides >400Mpts for record lengths of 50kpts to 25Mpts, with a maximum of 433.5Mpts at a record length of 500kpts (>=430Mpts for record lengths of 1, 2.5 and 5 Mpts).

R&S RTM3000: >400Mpts for record lengths of 200kpts to 20Mpts, with a maximum of 428Mpts at a record length of 2Mpts.

There’s still the fact that the SDS5000X can have record lengths up to 250Mpts, whereas the RTM3000 is limited to 80Mpts.

 
The following users thanked this post: tautech, 2N3055

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 17660
  • Country: nl
    • NCT Developments
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #130 on: February 09, 2019, 12:40:37 am »
The problem with deep memory is that a powerful processor is needed to do something useful with it. It is interesting to see how the SDS5000X deals with decoding and math for example. Doing a search in a trace of 250Mpts may take forever. The RTM3000 already needs a few seconds to search through 80Mpts for a simple condition. With great memory comes the need for great processing power.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4312
  • Country: au
  • Question Everything... Except This Statement
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #131 on: February 09, 2019, 03:26:48 am »
I feel I should ask this, If the decoding done by the FPGA, or by the ARM CPU?

Seeing as they are sticking to simple protocols I suspect FPGA based, in which case it can probably decode as fast as the sample rate, but I'm curious.
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4312
  • Country: au
  • Question Everything... Except This Statement
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #132 on: February 09, 2019, 09:32:08 am »
Don't know what of this is known, but there have been some not easily navigable pages appear for all the purchasable Option Codes.

SDS-5000X-4BW05
SDS-5000X-2BW05
SDS-5000X-4BW10
SDS-5000X-2BW10
SDS-5000X-FG
SDS-5000X-16LA
SDS-5000X-I2S
SDS-5000X-FlexRay
SDS-5000X-CANFD
SDS-5000X-1553B
 

Offline Performa01

  • Frequent Contributor
  • **
  • Posts: 817
  • Country: at
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #133 on: February 09, 2019, 11:16:53 am »
The problem with deep memory is that a powerful processor is needed to do something useful with it. It is interesting to see how the SDS5000X deals with decoding and math for example. Doing a search in a trace of 250Mpts may take forever. The RTM3000 already needs a few seconds to search through 80Mpts for a simple condition. With great memory comes the need for great processing power.

One of the main reasons for deep memory is the legitimate request for analyzing signals that contain vastly different frequency components at the same time, such as narrow pulses at low repetition rate, without the need to bother with crouches like peak detect, which would destroy the original waveform and is therefore utterly useless for any kind of signal analysis.

The SDS5000X can maintain full sample rate up to 5ms/div, so we can capture a 50ms record without losing any detail (which can be inspected in zoom mode) and without giving a second thought about aliasing.


SDS5104X_Mem_250Mpts_Zoom_1ns

Attached is a short (5s) video in an archive “Search 02.zip” that contains the mp4 and demonstrates the search speed by showing a sine wave with periodic exponential increase in amplitude, which also leads to an increasing slew rate. The scope triggers on the sync signal of the signal generator, while the search function looks for edges that have a slew rate faster than some 7mV/µs. These settings are not entirely unambiguous on purpose, because this causes the search function to be undecided, hence toggle randomly between considering the second to last rising edge as a hit or not and each individual search yields different results. Because of this, we can get a good visual impression and the search function runs at least 15 times in this short video, so it certainly doesn’t take “forever”.


I feel I should ask this, If the decoding done by the FPGA, or by the ARM CPU?

Seeing as they are sticking to simple protocols I suspect FPGA based, in which case it can probably decode as fast as the sample rate, but I'm curious.
If these protocols are “simple”, which ones would be complicated?

Triggering is performed in hardware (FPGA), since it has to work in real time.

Decoding is a task for the MCU, because it is done after the acquisition of a record is complete. Of course the decoders can use the full sample rate, but there always has to be a bit of oversampling, since the internal sample clock is asynchronous with regard to the serial data stream. Traditionally, the decoders don’t need much oversampling.

 

Online 0xdeadbeef

  • Super Contributor
  • ***
  • Posts: 1315
  • Country: de
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #134 on: February 09, 2019, 11:23:54 am »
Some scopes are said to use "HW based" decoding. I could imagine the FPGA is used to detect/measure periods from the raw sampled data. It sure speeds up a SW decoder a lot if you can jump from edge to edge instead of going from sample to sample.
Trying is the first step towards failure - Homer J. Simpson
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4312
  • Country: au
  • Question Everything... Except This Statement
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #135 on: February 09, 2019, 11:36:38 am »
By simple I meant mainly confined to single ended signals, and work off a high / low state, e.g. something that FPGA's specialize in.

Still makes me glad to know its software which can be patched, not bit streams that need to be reverse engineered.
 

Online 0xdeadbeef

  • Super Contributor
  • ***
  • Posts: 1315
  • Country: de
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #136 on: February 09, 2019, 11:44:23 am »
Well, perhaps the folks at Keysight are confused too (quote from DSOX3000T datasheet):
Quote
Segmented memory optimizes available memory for data streams that have long dead times between activity. Maximum segments = 1000. Re-arm time = 1 μs (minimum time between trigger events)
This is perfectly correct. The maximum dead/blind time defines the minimum time between trigger events.
However, the siglent data sheet says "The dead time between segments can be as small as 2 μs." which is at least inartfully expressed. Maybe they are trying to say "the time between trigger evens can be as small as 2µs" but by using the term "dead time", they kinda inverted the meaning.
Trying is the first step towards failure - Homer J. Simpson
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 16012
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #137 on: February 28, 2019, 09:22:11 pm »
New publicly available firmware for the SDS5000X series.

This may be the release version as there are no items in the changelog.  :-//

Version V0.8.0R1B5
38.6 MB
http://old.siglentamerica.com/USA_website_2014/Firmware&Software/firmware/SDS5000X_0.8.0R1B5_EN.zip
Avid Rabid Hobbyist
 

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 3069
  • Country: fi
  • Starting with DLL21
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #138 on: March 01, 2019, 06:51:37 pm »
This may be the release version as there are no items in the changelog.  :-//
Version V0.8.0R1B5

Perhaps or then not... ;)
If practice and theory is not equal it tells that used application of theory  is wrong or the theory itself is wrong.
It is much easier to think an apple fall to the ground than to think that the earth and the apple will begin to move toward each other and collide.
 
The following users thanked this post: tautech

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 17660
  • Country: nl
    • NCT Developments
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #139 on: March 01, 2019, 06:54:44 pm »
How can they thouroughly test releases which are released with so little time in between?  :-// Who says fixing one bug doesn't introduce another one?
« Last Edit: March 01, 2019, 09:01:56 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Performa01

  • Frequent Contributor
  • **
  • Posts: 817
  • Country: at
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #140 on: March 01, 2019, 09:33:24 pm »
How can they thouroughly test releases which are released with so little time in between?  :-// Who says fixing one bug doesn't introduce another one?
Oh yes this would be a valid point - if there were any releases at all. But as anyone really interested in the topic can see, there are none as yet (20190301/22:30):

https://www.siglenteu.com/service-and-support/firmware-software/digital-oscilloscopes/#sds5000x-series

https://www.siglentamerica.com/service-and-support/firmware-software/digital-oscilloscopes/#sds5000x-series

Just because quite obviously it has become fashionable to advertise internal beta releases, this does not mean that there will be any official release without thorough production testing.
 

Offline bugi

  • Frequent Contributor
  • **
  • Posts: 250
  • Country: fi
  • Hobbyist using the ultra slow and unsure method
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #141 on: March 01, 2019, 11:47:43 pm »
How can they thouroughly test releases which are released with so little time in between?  :-// Who says fixing one bug doesn't introduce another one?
It depends on the type of bugs, too. For example, fixing typos or a small change UI color are obviously quite small and independent changes, and easy to "test" (more like "check/confirm that the change got in"). Another example might be e.g. simple fix on DSP math with samples; changing sample values a bit will obviously not break the rest of the math chain (assuming the math is done in a usual way, using "normal" numbers and functions). In these cases, it would be enough to just check that the change/fix itself works.

But of course there are plenty of bugs/changes that (can) mess up a lot, too.

As part of longer development process, devs can choose to e.g. bring lots of easy changes first (with quickly made version(s)), collecting bigger changes to a specific later version which then needs more testing.  At least we do this kind of development with our software, so that we don't have to do the multi-day testing ordeal on every release; small independent changes can be tested as part of the fix process of each individual issue, and a release then rolled out in few hours with few cursory checks.

And the internal-versions vs. actual public releases -stuff as already mentioned by Performa01. Although considering the history, I am quite skeptic on the "...not mean that there will be any official release without thorough production testing" -part :P  But one can always hope for better..
 
The following users thanked this post: Martin72

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 17660
  • Country: nl
    • NCT Developments
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #142 on: March 01, 2019, 11:58:44 pm »
How can they thouroughly test releases which are released with so little time in between?  :-// Who says fixing one bug doesn't introduce another one?
It depends on the type of bugs, too. For example, fixing typos or a small change UI color are obviously quite small and independent changes, and easy to "test" (more like "check/confirm that the change got in"). Another example might be e.g. simple fix on DSP math with samples; changing sample values a bit will obviously not break the rest of the math chain (assuming the math is done in a usual way, using "normal" numbers and functions). In these cases, it would be enough to just check that the change/fix itself works.
I wouldn't bet my life on that. I've seen weird bugs pop up due to simple fixes. Sure pre-release versions aren't fully tested but look at the lift rf-loop posted. There is about 5 weeks between V0.8.0R1B5 and the previous version. No way there has been some serious development AND testing going on in such a short time frame. I'm involved in software engineering projects myself and much simpler software products take a week to test.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 16012
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #143 on: March 02, 2019, 12:13:11 am »
How can they thouroughly test releases which are released with so little time in between?  :-// Who says fixing one bug doesn't introduce another one?
It depends on the type of bugs, too. For example, fixing typos or a small change UI color are obviously quite small and independent changes, and easy to "test" (more like "check/confirm that the change got in"). Another example might be e.g. simple fix on DSP math with samples; changing sample values a bit will obviously not break the rest of the math chain (assuming the math is done in a usual way, using "normal" numbers and functions). In these cases, it would be enough to just check that the change/fix itself works.
I wouldn't bet my life on that. I've seen weird bugs pop up due to simple fixes. Sure pre-release versions aren't fully tested but look at the lift rf-loop posted. There is about 5 weeks between V0.8.0R1B5 and the previous version. No way there has been some serious development AND testing going on in such a short time frame. I'm involved in software engineering projects myself and much simpler software products take a week to test.
Sure, for a small team.

Current SDS5000X beta testers are worldwide and yes a few are EEVblog members too, some of very long standing and experience. Knowing just a few of them I have full faith that they in conjunction with the factory know exactly what they are doing.

Of course it seems the FW version I linked was a beta version (B5) that one might assume has been tested well enough for V08.1R1 shown in rf-loop's list to now be the latest version.

Why was B5 placed on the factory website firmware page, well a 38.6MB file might offer issues to send as an email attachment through some email providers.
Anyways, it's just conjecture as now V08.1R1 seems like the latest version for the beta testers to test with.
Avid Rabid Hobbyist
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 17660
  • Country: nl
    • NCT Developments
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #144 on: March 02, 2019, 12:43:32 am »
Letting a few people do random testing isn't software testing but stabbing around in the dark. When I do an oscilloscope review I spend about 20 to 30 hours on testing and I'm not even close to covering 10% of all features. Real software testing means going through each and every function & feature for every possible permutation according to a test plan. For a modern oscilloscope this will take at least 3 to 4 weeks fulltime and it needs to be repeated for every release. And even then the testers won't be able to catch all bugs (which is where beta-testers come in). Test plans usually evolve over time to also catch the more elusive bugs. Software testing is expensive & time consuming and it is tempting to skip it but it will come back and haunt you if you do skip software testing.
« Last Edit: March 02, 2019, 12:52:40 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline bugi

  • Frequent Contributor
  • **
  • Posts: 250
  • Country: fi
  • Hobbyist using the ultra slow and unsure method
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #145 on: March 02, 2019, 09:39:34 am »
Letting a few people do random testing isn't software testing but stabbing around in the dark.
That sentence assumes that the few people random testing is all there is. I'd think they do much more (still not necessarily enough).

Quote
When I do an oscilloscope review I spend about 20 to 30 hours on testing and I'm not even close to covering 10% of all features. Real software testing means going through each and every function & feature for every possible permutation according to a test plan. For a modern oscilloscope this will take at least 3 to 4 weeks fulltime and it needs to be repeated for every release. And even then the testers won't be able to catch all bugs (which is where beta-testers come in). Test plans usually evolve over time to also catch the more elusive bugs. Software testing is expensive & time consuming and it is tempting to skip it but it will come back and haunt you if you do skip software testing.
The last sentence I can agree 90%. It is often more expensive to skip some testing, yet in many cases much cheaper to do risk management, skip some testing and do few fixes afterwards. It is details of where one can vs. should not skip some testing where I apparently disagree.

The need for full multi-week (or in our case "just" few days) testing only applies when there is either no previous testing done at all (like the situation for an external reviewer, or first release), or when the system is critical (say, space ships or nuclear power facility or such), or if risk management indicates so (like typically for so called "major releases" which have likely collected many changes that have inter-dependencies). As I mentioned before, in practical projects, simple fixes that can be seen clearly to be independent from the rest of the system do not create a need to make full 100% all permutations included -type of testing. Doing full tests for any tiny change would be like shooting a fly with a tank, there is simply no sanity in doing do so in most software projects, including oscilloscopes. (Unless that scope goes into space/nuclear power facility, but in that case, the responsibility and coverage of testing is managed by that project, not by the scope manufacturer).

Sure, sometimes a developer makes a mistake and a "clearly simple" fix ends up having side-effects after all, but these are (at least for us) very rare, and typically are not a disaster even if they slip through. And even when we know a change can have wider effects we still limit testing, simply for keeping the costs sane. Much cheaper to have few micro-level releases afterwards (typically come out in few days between each after a major release) than do the 100% testing beforehand.

That is simple common sense and economic thinking. I'm not the budget manager, and I'm actually one of the most testing-demanding coders in our sub-organization, but even then, I do apply some common sense when deciding testing coverage (per fix and per release).

We do run automated tests (unit tests and some integration tests) on every release, they only take about 2 minutes of work to start and a 50 minutes coffee-break. But those tests won't really cover a lot, especially not UI.


And in the end, it is the customers that define the level of testing they want. If they want 100% testing for every little thing, they need to pay for it. None of our customers have been ready to do so, not even close. Siglent/Rigol customers seem to be typically even less willing to do so.


In short, the "short" time between versions is not (necessarily) a problem here, even if they had been public releases. I'd be fine with even public releases with just one day in between, if the latter release's changelog states merely "changed words chanel->channel, current->selected".

My negative "feelings" towards Siglent's software dev side has grown mostly from them (previously) letting through many bugs that are so obvious to detect that even quick (thus cheap) testing would have caught them, and many of them being so simple (thus cheap) to fix that there really was no excuse for those bugs ever to be seen in public. But all this external beta-testing stuff seems to indicate Siglent is growing up.
 

Online 0xdeadbeef

  • Super Contributor
  • ***
  • Posts: 1315
  • Country: de
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #146 on: March 04, 2019, 11:08:53 pm »
For the record: someone at Batronix finally noticed that the price for the 1GHz update was wrong. It's 2.450,21€ now including VAT.
Trying is the first step towards failure - Homer J. Simpson
 

Offline tv84

  • Frequent Contributor
  • **
  • Posts: 861
  • Country: pt
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #147 on: March 04, 2019, 11:48:25 pm »
This probably is old news but, according to the bitstreams, it has 2  Xilinx Artix-7 XC7A200T (Part Name: 7a200tffg1156) and a Xilinx Zynq-7020.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 17660
  • Country: nl
    • NCT Developments
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #148 on: April 08, 2019, 04:08:08 pm »
Did anyone do a really in-depth review / testing yet?
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online 2N3055

  • Super Contributor
  • ***
  • Posts: 2087
  • Country: hr
Re: At last, Siglent's SDS5054X touchscreen DSO...
« Reply #149 on: April 08, 2019, 04:42:32 pm »
Did anyone do a really in-depth review / testing yet?
Not that I know of.
I would like  to compare it to MSOX3104T but I'm not prepared to buy one just for that.. It would be interesting to see how it compares in real life scenarios.. I really like the general concept..
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf