Siglent SDS5104X: Disappointing^H^H^H (ehh...maybe) - Page 1
Forum section: electronics / testgear

author: tom66
author_rank: Super Contributor
timestamp: March 02, 2020, 08:21:59 am
content: Got a Siglent SDS5104X from a UK distributor for evaluation purposes. 1GHz, 4 channels, 5GSa/s. Price very competitive - around £5,600+VAT.A number of issues that mean it won't be going on our bench here:1. The intensity grading isn't particularly good. It seems to have a fair few levels, but if you change the intensity control, you can't actually *see* them. The DSOX1102G, an oscilloscope at 1/6th the price of the Siglent, has better intensity grading when testing on both noise and sine, and the Siglent is barely better than my Rigol DS1074Z - which is ~4 years old now.2. The serial decode doesn't work when zoomed out. It works when zoomed in. But this means it's got the same limitation as the DS1074Z, which limits you to decoding on-screen pixels, at a sample rate lower than what is actually being acquired (unless I'm missing something here!) Also, I've noticed if you zoom in to a stopped waveform, the data bus outside of the zoom is deleted, which makes zooming into a large window to decode a pain.3. A similar limitation applies for the automatic measurements function making the "Count N Edges" function essentially useless (it would be nice to be able to count the number of edges between two cursors but it doesn't work when zoomed out, even on large memory depths. I can manually count edges at high zoom levels, so this function has little use.)4. I've managed to crash the touchscreen driver at least once (yes, "Touch" was still enabled.)The annoying thing is that these limitations appear to be primarily software. The hardware is otherwise quite decent.Disclaimer:While I have attempted to be unbiased in this brief summary of issues with the Siglent instrument, I have interest in the development of competing products.

author: tom66
author_rank: Super Contributor
timestamp: March 02, 2020, 08:43:07 am
content: Software 0.8.7R1B1U-Boot 4.6FPGA 2019-08-07CPLD 13Hardware 02-01MCU 18053101This is from a UK Siglent distributor. They assured me it has latest f/w.

author: tautech
author_rank: Super Contributor
timestamp: March 02, 2020, 09:14:10 am
content: Yep that's the latest, thanks.SDS5054XSDS5104X here.These can decode 1000's of packets and display them in a scrollable list when you know how and it's really dead simple. Slow your timebase right down to get as many packets as you like on the display then press the timebase knob for Zoom mode then adjust again to get a full packet on the display, then you can walk using the horizontal position anywhere in the bitstream....even off the source display to the limits of the horizontal position !Like this:Anything else you want to work through just please ask or put screenshots up so we can look at each issue.

author: tom66
author_rank: Super Contributor
timestamp: March 02, 2020, 09:18:56 am
content: You're right. I didn't try the zoom function. I just tried the serial decode when zoomed out expecting it to be able to decode everything in that span (aware that it might take a second to do this.) I would hope that the Siglent wouldn't have the context issue that the Rigol has - where I2C buses need to have the stop/start on the display to decode correctly? (This makes decoding I2C buses a pain on my 1000Z, as you can only see ~8 bytes at a time.)

author: tautech
author_rank: Super Contributor
timestamp: March 02, 2020, 09:27:49 am
content: Quote from: tom66 on March 02, 2020, 09:18:56 amNope, firstly you must have a dead steady packet that results from rock solid triggering.For simple decoding examples like the one above I use a falling edge and trigger holdoff set to a bit wider than 1 packet, in that case 2ms. Levels and thresholds need be right too.Have a play with Zoom and the List.Any bugs found please write them up so they can be reproduced.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: March 02, 2020, 09:33:44 am
content: The zooming in for decoding probably makes sense but things like counting edges have to work without zooming in. So is this a bug?

author: tom66
author_rank: Super Contributor
timestamp: March 02, 2020, 10:33:10 am
content: Scrub the serial decode - I must have been using it wrong (or triggered a bug, but I'll put this down as user error for the time being.)However "Count N Edges" definitely does not work when zoomed out - see attached. I don't think this is a bug, just a design limitation. They are probably using a sub-sampled capture to make measurements on, rather than doing this in DSP blocks on the FPGA.It also supplies a fractional value for the result. Not a problem, but I wonder what a fractional edge would look like!Memory depth of 250M for all captures.

author: tautech
author_rank: Super Contributor
timestamp: March 02, 2020, 10:38:15 am
content: Quote from: 0xdeadbeef on March 02, 2020, 09:33:44 amNope.Edges can be counted with or without a gate. Same display as before with Decode OFF, Measure ON and P-edge selected. See screenshots.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: March 02, 2020, 10:41:40 am
content: But counting edges or other measurements without the zoom window don't work???This looks like measurements really done from the (zoomed) display buffer instead of the measured data. This would be plain terrible.

author: nctnico
author_rank: Super Contributor
timestamp: March 02, 2020, 10:43:50 am
content: QuoteNo. Look carefully!

author: tautech
author_rank: Super Contributor
timestamp: March 02, 2020, 10:49:12 am
content: Quote from: 0xdeadbeef on March 02, 2020, 10:41:40 amDo you understand the count of 9000+ is of clock edges from the main timebase setting and 126 is gated within the zoomed display ?Yes I could have made the gate wider than the zoomed display and got 9000+ or a bit less.The gate indicators spanned outside the zoomed display so it wasn't as clear as bringing them in some.They work perfectly fine on a stable and properly triggered waveform.

author: tautech
author_rank: Super Contributor
timestamp: March 02, 2020, 11:01:58 am
content: Just so there is no doubt edge counting works as expected, a 100 pulse burst from a Siglent STB3 captured in Single shot mode.

author: nctnico
author_rank: Super Contributor
timestamp: March 02, 2020, 11:03:45 am
content: Quote from: tautech on March 02, 2020, 11:01:58 amTry to zoom out further so your 100 pulses have the same width as shown in tom66's picture.

author: exe
author_rank: Unknown
timestamp: March 02, 2020, 11:17:24 am
content: So, @tom66, what's the conclusion? Can it do better than Rigol DS1074Z?

author: tautech
author_rank: Super Contributor
timestamp: March 02, 2020, 11:22:58 am
content: Quote from: nctnico on March 02, 2020, 11:03:45 am6 screenshots of the same captured 100 pulses for you to study. No measurement gate used until #10 when without a gate it misses the 100 pulse count.

author: nctnico
author_rank: Super Contributor
timestamp: March 02, 2020, 11:28:50 am
content: As part of a new acquisition ofcourse. Try to find the decimation point.

author: tom66
author_rank: Super Contributor
timestamp: March 02, 2020, 11:31:40 am
content: The captures attached are data acquired at 1ms/div with memory set to 250M - the highest sampling depth - obviously the short capture window means that the full data is not captured, but there is data there at the sampling rate of the ADC. Nonetheless, if you zoom in on a stopped capture, the N-edges function works correctly. I think this demonstrates that the measurement function is sub sampling the data that is sent for display, but I would be happy to be shown to be wrong!There is no similar function on the DS1074Z or the DSOX1102G that I have access to - so comparison here is not possible. However, we do have a Tek MDO34 on demo next week, so I suppose I will do the same test on that. Tek instruments have previously been the only ones that have passed this test for me, although the measurement engine on those is -very slow- which is probably a consequence of this behaviour.Edit: corrected brain-o.

author: tom66
author_rank: Super Contributor
timestamp: March 02, 2020, 11:45:14 am
content: Quote from: tautech on March 02, 2020, 11:22:58 amRepeat the last test with the acquisition zoomed out, stop the instrument and tell me if N edges still works. It seems that it works if you have the timebase short when you stop, but not if you have the timebase set to a longer value. (So the blank area on your trace would now be filled in.) I think there's a sample limit for the measurements. Above that sample limit it starts to sub-sample the measurement data.Edit: there's a forum bug preventing further posts from showing...

author: tautech
author_rank: Super Contributor
timestamp: March 02, 2020, 11:49:09 am
content: Quote from: nctnico on March 02, 2020, 11:28:50 amNew single shot captures with timebase settings that allow for the correct count and the slower prohibits a count.Same as before, 100 pulses.

author: tautech
author_rank: Super Contributor
timestamp: March 02, 2020, 12:14:15 pm
content: New single shot captures with timebase settings that allow for the correct count and the slower prohibits a count.Same as before, 100 pulses.Then add a gate:

author: tom66
author_rank: Super Contributor
timestamp: March 02, 2020, 12:19:21 pm
content: Tautech, your post seems to have broken EEVBlog forum. It's crashed right at the start of it!

author: nctnico
author_rank: Super Contributor
timestamp: March 02, 2020, 12:45:59 pm
content: Quote from: tom66 on March 02, 2020, 11:31:40 amThere are very few brands which do math on the acquired data because it is relatively slow. Besides Tektronix the only brand I know of is GWI but they don't have anything in the higher end segment you seem to be looking at.

author: tautech
author_rank: Super Contributor
timestamp: March 02, 2020, 12:59:29 pm
content: Quote from: tom66 on March 02, 2020, 12:19:21 pmYeah I know.Pulled the USB stick too early and one png screen capture was corrupt and I didn't check it before posting.However we can still read one anothers posts if you go to their profile and read their last posts.Once we hit P2 of the thread it should come right again.

author: Simon
author_rank: Unknown
timestamp: March 02, 2020, 04:18:07 pm
content: clicking "reply" on any post will allow you to answer while someone looks at this.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: March 02, 2020, 04:32:23 pm
content: Quote from: nctnico on March 02, 2020, 12:45:59 pmI guess you mean measurements, not math. If so: all (real/black) LeCroy scopes perform measurements always on the whole data buffer. You should know better, but I faintly recall that someone claimed this was also true for R&S. Anyway, I kinda hoped Siglent would follow LeCroy there and not the refresh rate addicts. I know that other people will disagree but for me, using anything else but the acquired data for measurements is a showstopper.Besides, letting aside if it's worth to sacrifice the whole idea of a large memory measurements for fast refresh rate: this whole argument becomes totally invalid when the measurement is stopped. And my understanding is that the SDS5000X won't update the measurements even then unless you zoom in.

author: nctnico
author_rank: Super Contributor
timestamp: March 02, 2020, 04:43:48 pm
content: Quote from: 0xdeadbeef on March 02, 2020, 04:32:23 pmWell, Lecroy 'only' does math / decoding from what is on screen so unless you choose a long enough time/div setting which has the full memory you won't get full memory math / measurements. But the real trade-off is math / measurement update speed versus memory depth. It would be nice if that was left to the user. On R&S and Keysight scopes math & measurements are performed on decimated data and not the acquisition memory. This is fine for as long as you can see the shape of a waveform but numerical analysis of a long trace won't work. I agree it would be nicer if the choice to wait for a correct answer would be left to the user. AFAIK Keysight and R&S do show that the result of a measurement is invalid instead of 0 (like Siglent shows).

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: March 02, 2020, 05:10:39 pm
content: Quote from: nctnico on March 02, 2020, 04:43:48 pmAgain, counting edges is a measurement, not a math function. And all LeCroys I ever used always did measurements on the whole acquired data. There is no discussion about this.I am aware that you have a different view on the whole offscreen/onscreen thing compared to most other scope users and I don't want to start this whole discussion here again, so let's put it this way: I don't care if 99% of all scopes on the market don't capture much more than they display. Idocare though about them using all of this data for measurements. Again: not doing so is a showstopper for tasks which need reliable measurements. At work, I wouldn't accept a scope that stops measuring if there's "too much" data or one that performs inaccurate measurements from screen data to save time.

author: tom66
author_rank: Super Contributor
timestamp: March 02, 2020, 07:33:37 pm
content: Counting edges would be relatively trivial to do on the acquired data, it is essentially a post-acquisition trigger. A zone trigger is already implemented, which is a post-acquisition trigger, so it should not be too expensive in terms of logic to implement if the architecture is similar to what I am thinking of.In fact, thinking about it, the following elements should all be quite trivial to do on the FPGA, rather than after-the-fact:- VMin- VMax- VAvg- Duty cycle On%/Off%- Period- Frequency- N-EdgesThey would require at most a few counters on the FPGA, plus a DSP block.Now the argument could be made that they are pushing the FPGA to the limit, but the £5,600 price tag of this instrument suggests it would have (at least) a Zynq UltraScale or a Kintex-7 for instance, which would have almost 250K LUTs available at a £500 chip price point. A 24-bit counter doesn't take more than a few CLBs...

author: tautech
author_rank: Super Contributor
timestamp: March 02, 2020, 07:56:45 pm
content: Screenshots of 100 Ppulses Single shot Bursts showing where count fails and how a gate can make this measurement possible.Count fails in #7 screenshot and #10 with a gate set succeeds.

author: maginnovision
author_rank: Super Contributor
timestamp: March 02, 2020, 08:05:19 pm
content: Wouldn't you naturally expect it to work either way though? Gating is used for... gating. Usually. This definitely seems like a bug. How large can the gate be before it fails again?

author: tom66
author_rank: Super Contributor
timestamp: March 02, 2020, 08:50:04 pm
content: I suspect the only reason gating works is because it has reduced the sampling window to an acceptable range. If you attempted the same with 1000 pulses at a longer timebase, it may not work so well.

author: nctnico
author_rank: Super Contributor
timestamp: March 02, 2020, 09:03:39 pm
content: Quote from: tom66 on March 02, 2020, 07:33:37 pmGenerally speaking: IMHO using an FPGA with an embedded CPU is the wrong choice nowadays for an oscilloscope. A SoC with a decent GPU provides a lot more processing power with a much shorter software development cycle. I think we'll see these kind of oscilloscopes soon if they don't exist already.@0xdeadbeef: The point to take away is that oscilloscope manufacturers have very different ideas about how very basic operations on an oscilloscope should work. And none of these result in real unique selling points (rather the opposite). I'd expect that things would be more standardised by now. But it isn't.

author: tautech
author_rank: Super Contributor
timestamp: March 02, 2020, 09:06:48 pm
content: Quote from: tom66 on March 02, 2020, 08:50:04 pmMeasurements work fine. All screenshots I've taken the effort to post show any limits and the workarounds.Examples were kept simple for anyone to follow.Please post screenshots demonstrating where they don't work so we can examine you use style and/or errors made.

author: tom66
author_rank: Super Contributor
timestamp: March 02, 2020, 10:04:44 pm
content: Quote from: tautech on March 02, 2020, 09:06:48 pmI attached pictures earlier, I am away from the office right now so we'll have to wait for the thread to be un-broken by a moderator or technical person.However, the principle problem is that NCycle measurement fails when zoomed out, if the measurement represents a small measurement area of the total waveform. I imagine this occurs in the scenario when the frequency of the measurement gets close to the sampling rate (hopefully Siglent are using a filter on their measurement subsampler to reduce alias errors.)I don't believe this is a bug, but instead a limitation of the design/processing power.

author: tautech
author_rank: Super Contributor
timestamp: March 03, 2020, 07:10:47 am
content: Discussions of measurements kinda spilt over into the SDS2000X Plus thread so let's bring it back here.Nico mentioned PWM waveforms and as it happens the STB3 provides one.Colored trace active and 1s of persistence plus a few inbuilt measurements etc.

author: Someone
author_rank: Super Contributor
timestamp: March 03, 2020, 08:24:25 am
content: Quote from: tom66 on March 02, 2020, 07:33:37 pmThat would be the DVM/voltmeter/counter/frequency meter that runs independently to acquisition recent in models from Rigol, Keysight, Tektronix, even Lecroy

author: tom66
author_rank: Super Contributor
timestamp: March 03, 2020, 09:43:38 am
content: Pictures attached of example "failure".Below shows a SPI transaction to an LED driver.Count pulses on C2 works when zoomed in (500ns/div), but does not work when zoomed out (10us/div). If instrument is stopped on 10us/div setting and zoomed into a packet, then count works correctly.Unfortunately, this makes the count edges function essentially useless, at least for my application, as it can only count small numbers of edges. Generally, I have found count n-edges before to be useful for checking if the required number of bytes were written, or estimating bus speed with overheads.This doesn't rule out the instrument in the whole, but it's a disappointing limitation.

author: tautech
author_rank: Super Contributor
timestamp: March 03, 2020, 07:06:39 pm
content: Quote from: tom66 on March 03, 2020, 09:43:38 amTom, I'm not so sure the scope is the entire issue when I study your screenshots.As I see it the most powerful part of the scope is not being used correctly, namely the trigger and the operators skill to spot such an obvious error.What on earth am I talking about....the trigger settings and their correlation to the STOPped waveform.This immediately points to the level set which reveals the problem that can simply be avoided by pressing the level control and so set the level to 50% of the waveform.Unless this is done the technical peoples at Siglent would throw such a screenshot back in my face as it overlooks proper use of a scope.As for investigation of edge counting we should also examine if the trigger set to the channel we want counted and trigger level has any bearing on results.I have runt and glitch waveforms on the STB3 that will be perfect to test this and later I will examine and post results.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: March 03, 2020, 07:25:44 pm
content: Are you saying that measurements are only working correctly for for the channel triggered on? So no reliable measurements on the other channels? Seriously?This would be the first and only scope to behave that way. Typically scopes determine the min/max amplitudes and use around 50% of that for hi/lo detection (and browsing through the manual I'm pretty confident this is also true for the SDS5000X). Really good scopes let you specifically define the threshold for each measurement separately.

author: nctnico
author_rank: Super Contributor
timestamp: March 03, 2020, 07:29:37 pm
content: Quote from: tautech on March 03, 2020, 07:06:39 pmAsk yourself: if the trigger level has any relevance to measurements, then how are measurements supposed to work on channels which aren't triggered on?Oh, and please stop trying to ridicule other posters. You are not dealing with a bunch of noobs here. It is clear you are very defensive of your livelyhood but it gets to the point where it is counterproductive quickly. There is some excellent feedback for Siglent to improve their product right here on your doorstep.

author: tautech
author_rank: Super Contributor
timestamp: March 04, 2020, 12:37:42 am
content: Quote from: nctnico on March 03, 2020, 07:29:37 pmLet's examine if stable triggering really does have an impact on measurements, well it doesn't apparently.Edge measurements of a runt pulse from STB3 shown below are from running live waveforms but one is with stable triggering, one without and another STOPped. Screenshots whose triggering was not stable displayed constantly updating measurement values until the point they were captured.

author: maginnovision
author_rank: Super Contributor
timestamp: March 04, 2020, 01:54:25 am
content: So is it still his fault and definitely not a bug? Would siglent still tell you to go to hell with your screenshots and bug reporting? I really don't get how you say everyone has bugs but this bug definitely is user error and nothing else.

author: tom66
author_rank: Super Contributor
timestamp: March 04, 2020, 07:37:35 am
content: Quote from: tautech on March 04, 2020, 12:37:42 amRepeat this test with the instrument zoomed out so that you have a similar display to mine (where the intensity grading starts to blend adjacent edges in.)I am willing to believe this is a bug if it affects only some firmware but I cannot get the instrument to reliably measure N edges on longer timebases, if the frequency of the edge is moderately high. In fact, I have been unable to get the measurements to work at all well when at a long timebase, for any test case. Perhaps you can replicate my test to satisfy yourself. Any SPI bus ought to do.

author: tautech
author_rank: Super Contributor
timestamp: March 04, 2020, 07:59:59 am
content: Quote from: maginnovision on March 04, 2020, 01:54:25 amI answer you with further questions.Is it a bug, a design limitation or user error ?It is vitally important any bug report with accompanying screenshots to be accurate as possible so to exclude any errors and risk the possibility of wasting the engineers time so documentation should be high quality without the chance of any result other than expected. That a screenshot was offered with the trigger level acting on overshoots is not of high quality as it could also be within the range of trigger hysteresis only to further complicate the chance of faithful reproduction.Is the failure to return accurate measurements at some timebase/waveform combinations a bug ?No, but it does appear to be a design limitation as far as my investigations reveal and one that is improved upon by use of a measurement gate as we shall see.Some examples of measurements that are apparently just pulses or are they ?All is not what it seemsAt the threshold of reliable measurementsBursts of 20 pulses ex continuous burst mode STB3Might someone else also examine the measurement thresholds of their current midrange DSO ?

author: tom66
author_rank: Super Contributor
timestamp: March 04, 2020, 10:25:07 am
content: On Monday, we'll have the Tek MDO34 in for evaluation, so I'll let you know.I'm not sure you could call an instrument with a £10k price point "midrange" though!

author: tautech
author_rank: Super Contributor
timestamp: March 04, 2020, 10:46:20 am
content: Quote from: tom66 on March 04, 2020, 10:25:07 amLow midrange actually, just as the SDS5kX are.Anything other than the Tek coming for assessment ?

author: tom66
author_rank: Super Contributor
timestamp: March 04, 2020, 10:56:28 am
content: We are trying to get hold of a Rigol MSO7000 too, but the UK distributor is out of stock. Might lose Rigol a sale.

author: tautech
author_rank: Super Contributor
timestamp: March 04, 2020, 11:02:46 am
content: Quote from: tom66 on March 04, 2020, 10:56:28 amYou should ask Wuerstchenhund for a recommendation as he fits out many labs as part of his job. Based on your needs and budget he could give good advice.

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: March 04, 2020, 11:04:29 am
content: Quote from: tom66 on March 04, 2020, 10:25:07 amFor Tektronix 10k€ ( or $ or £ ) is a mid-range scopeBy the way, it is a very interesting discussion, I like it when people talk about specific examples of using their oscilloscope.This gives me ideas for measurement that I may not have thought of.If you want, if all goes well ( DHLLLLLL), tomorrow I will receive a Rigol MSO7000. if you give me specific examples of measurement, i can program a Nucleo446 or my AWG and and do the same.

author: Sighound36
author_rank: Frequent Contributor
timestamp: March 04, 2020, 12:32:29 pm
content: Quote from: tom66 on March 04, 2020, 10:25:07 amHaving gone through all of this just recently all be it at a more ' mid range point' lol and being pretty disappointed with the Tek MSO64, (not sure how a 'genuine 12 bit' scope manages 8 bits at certain frequencies! I would suggest looking at the either the Keysight or LeCroy alternatives (not a fan of R&S scopes) their RF products are another matter though!

author: Sighound36
author_rank: Frequent Contributor
timestamp: March 04, 2020, 12:35:36 pm
content: Quote from: tom66 on March 04, 2020, 10:56:28 amSpeak to Rigol UK pretty sure they have demo units Tom

author: tom66
author_rank: Super Contributor
timestamp: March 04, 2020, 01:00:35 pm
content: Quote from: Sighound36 on March 04, 2020, 12:35:36 pmThat was the UK disty. They had the 200MHz version but it was out on loan at the time we called. The other ones are order only from China, apparently.

author: Sighound36
author_rank: Frequent Contributor
timestamp: March 04, 2020, 01:08:10 pm
content: Hi TomYou may the situation has changed recently.I also have both the 7000 and 8000 models as well, rather than clog up this thread sent a PM

author: tom66
author_rank: Super Contributor
timestamp: March 04, 2020, 03:07:26 pm
content: @Sighound36, no PM received, but I sent one to you directly...Hmm, upon further testing I am reasonably sure that this is a bug!If the pulses are continuous the Siglent accurately counts them (see attached screenshot, counter shows 58kHz and timespan is 100ms so count around 5800 is correct.)So what causes it to miscount for short bursts?

author: nctnico
author_rank: Super Contributor
timestamp: March 04, 2020, 03:41:32 pm
content: Look at the number of samples in the acquisition (bottom right corner)!

author: tom66
author_rank: Super Contributor
timestamp: March 04, 2020, 04:01:08 pm
content: Nope, still does it at 12.5Mpts.I have discovered an interesting interpolator bug too.With the instrument set to 250kpts and Sinc interpolation enabled, acquisitions at 5~100us/div show ringing [1,2], but 200us/div does not , but 500us/div does  but 1ms/div onwards do not . Essentially, it seems that the sinc interpolator doesn't function correctly at all timebases on post-acquired data. Due to the level of ringing on the signal, compared to the dot mode data , I suspect what I am actually seeing here is a failed interpolator implementation, that is *only* working correctly at 200us/div and 1ms/div and above. The bug only occurs on Sinc mode , 'x' (linear interpolation) does not show the bug.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: March 04, 2020, 04:11:32 pm
content: At least sinc7.png looks OKish for me. The "ringing" there is more or less what you expect from sinc interpolation in contrast to linear interpolation. Is this what bothers you?

author: tom66
author_rank: Super Contributor
timestamp: March 04, 2020, 04:28:02 pm
content: Quote from: 0xdeadbeef on March 04, 2020, 04:11:32 pmWhat bothers me the most is the inconsistent performance, I'm not sure why the sinc filter is being applied at some timebases and not others, or if it is, why it is applied differently to the data at certain timebases.

author: exe
author_rank: Unknown
timestamp: March 04, 2020, 04:51:07 pm
content: I don't see problems on these pictures. Sampling rate should match the timebase, or you get "weird" aliasing issues. All scope I saw do things "right" when timebase is changed, unless someonemanually overrides sampling rate. For this reasons on all my scopes I set "peak detect" mode and sleep well since then.So...did you set sampling rate manually? If so, set to "auto", and set acquisition mode to "peak detect".

author: tom66
author_rank: Super Contributor
timestamp: March 04, 2020, 04:58:25 pm
content: The capture was the same, this is just "zoomed in" data. So the sampling rate is the same in every capture (you can see that in the screenshots, bottom right corner)There is no auto sampling rate or auto sampling memory mode on this Siglent, as far as I can see.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: March 04, 2020, 05:06:24 pm
content: If I had to guess, I would think it's some kind of subsampling issue when the data for the display is calculated.First of all, let me quote the manual:QuoteNow, this statement was either written by someone who didn't really understand the matter or was at least simplified to a degree that it became wrong, but the idea behind it is interesting: since there are 1000 pixels horizontally, interpolation between two sample points is only needed if there are less than 1000 sample points displayed. This is the case for your pictures 6 and 7, so the sinc interpolation shows its typical artifacts there.What this statement ignores is that there in case of steep edges, there might not be enough sample points to have a coherent signal even if there are >= 1000 sample points displayed. There could be other factors like certain odd fractions needed for subsampling etc.

author: exe
author_rank: Unknown
timestamp: March 04, 2020, 05:07:39 pm
content: It doesn't matter why sampling rate is low, it is clearly inadequate for the job. Why using 2.5MSa on a 5Gsa oscilloscope? You have 250Mpts of buffer, use it! Anyway, peak-detect would solve the issue.I'm also dubious about interpolation. I don't use it because I don't see any added value in it. Imho it only adds confusion and adds "details" that are not really present in signal. Why using it?

author: tom66
author_rank: Super Contributor
timestamp: March 04, 2020, 07:39:51 pm
content: You want to use a small sampling memory for short acquisitions as it speeds up the waveform update rate, increasing the chances of seeing a glitch.This is a fundamental trade off, nothing wrong with the Siglent here. Only select a larger sampling depth if you need it. Compare: Rigol DS100Z (and probably other Rigol kit), in Auto mode, selects the lowest sampling depth it can get away with to maximise waveform update rate.

author: tom66
author_rank: Super Contributor
timestamp: March 04, 2020, 07:41:26 pm
content: Quote from: 0xdeadbeef on March 04, 2020, 05:06:24 pmThe subsampling algorithm should take these edge cases into account by applying a filter to the data to calculate the subsampled result. So I believe the Siglent documentation is correct here: interpolation is not needed in the case of 1 pix >= 1 wavepoint.The problem appears to be that the subsampling algorithm occasionally causes sinc to be needed and occasionally does not, but it is not consistent in its application. In my opinion it should always have sinc enabled if sinc is selected and the 1 pix < 1 wavepoint criteria is met.

author: bson
author_rank: Unknown
timestamp: March 04, 2020, 07:52:37 pm
content: Quote from: nctnico on March 02, 2020, 04:43:48 pmNo, the current generation LeCroys ALWAYS decode and measure off the full acquisition record, never screen data. You don't have any other option, and it's why with deep acquisitions the update rates get very low, but you also get good measurement precision. They're not good beginner scopes because of this.

author: tautech
author_rank: Super Contributor
timestamp: March 04, 2020, 08:07:43 pm
content: Quote from: tom66 on March 04, 2020, 07:39:51 pmAt 5 GSa/s I fail to see the need for that approach. There are better tools in the scope for detection than needing to work with less data points, instead most want more.QuoteSame with Siglent's however I've never need to reduce the mem depth from max, rather let the scope manage it for best results and waveform fidelity/reproduction. As you can see from previous screenshots and discussion less data points risks less faithful reproduction although experienced DSO users might ignore the fine data only to concentrate on the big picture.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: March 04, 2020, 08:24:11 pm
content: Quote from: tom66 on March 04, 2020, 07:41:26 pmThe manual says there isno differencebetween vector and dot more for >= 1000 sample points per screen. There is no doubt that this is wrong for steep edges. In dot mode, there is no coherent edge, in vector mode there is. I agree though that using sinc interpolation is is nothing that would make much sense for vertical interpolation, but it's unclear what Siglent does there.

author: nctnico
author_rank: Super Contributor
timestamp: March 04, 2020, 09:05:53 pm
content: Quote from: bson on March 04, 2020, 07:52:37 pmYou took the quote out of the context which was full memory depth versus limiting memory depth to fit the screen (no recording beyond the edges of the screen). Lecroy sets the acquisition record length to what fits on the screen and uses that acquisition data for analysis functions. At least the Wavepro 7200 I have here does that and according to other sources this is normal Lecroy behaviour (which I don't like; if I set a certain acquisition depth I want that amount of data recorded even if it is off-screen).

author: nctnico
author_rank: Super Contributor
timestamp: March 04, 2020, 09:11:35 pm
content: Quote from: 0xdeadbeef on March 04, 2020, 04:11:32 pmI agree. Looking at the samplerate and bandwidth of the oscilloscope it is likely that the oscilloscope is fed with much steeper edges compared to the samplerate. Increasing the samplerate is likely to reduce the amount of ringing. Remember that a DSO is a digital sampling system with a lot of flexibility including producing signals on screen which may be false.

author: tautech
author_rank: Super Contributor
timestamp: March 04, 2020, 09:31:31 pm
content: Quote from: nctnico on March 04, 2020, 09:11:35 pm100% agree also and with your signature, any scope user should not blindly trust the waveform reproduced on the display and instead ask themselves is it what they expect to see ? A simple practice overlooked by many.When it's not as expected look at oneself and the settings you have chosen to use before trusting it or blaming the scope.

author: tom66
author_rank: Super Contributor
timestamp: March 04, 2020, 10:15:53 pm
content: Of course I understand what I'm seeing is incorrect - anyone seeing this ringing on the edges of a low sample rate signal should be suspicious. The problem I have here is more to do with the inconsistency in the application. Why is this overshoot present only at some timebases when paused? It is as if it is interpreting the data differently at different zoom levels, which is odd behaviour. The interpretation should always be consistent, in my opinion. And, outside of the 1pix>1wavept rule, Sinc interpolation need not be used. Why is it using it at higher zoom levels too, and inconsistently?

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: March 04, 2020, 10:21:02 pm
content: ntnico need to change his signature IMHO."There are small lies, big lies and then there is what is on recorded data even if it is offscreen"

author: tv84
author_rank: Super Contributor
timestamp: March 04, 2020, 10:23:44 pm
content: Quote from: jemangedeslolos on March 04, 2020, 10:21:02 pm

author: nctnico
author_rank: Super Contributor
timestamp: March 04, 2020, 10:27:38 pm
content: Quote from: tom66 on March 04, 2020, 10:15:53 pmIt isn't uncommon to see a change in amplitude when compacting waveforms. It has to do with how the data is decimated to show an outline of the waveform quickly. Ofcourse this goes wrong badly when the frequency is somewhat related to the sampling frequency. Turn on high res/eres (this term isn't used consistently among oscilloscope manufacturers) and start zooming in & out. You'll get the most fantastic waveforms! Yes, also on scopes from Keysight, R&S and Tektronix.@jemangedeslolos: Hmmm... no. Your suggestion doesn't have a nice ring to it. Maybe I should change it to:if oscilloscopes where cars then every car would have the pedals in a different order.

author: tautech
author_rank: Super Contributor
timestamp: March 07, 2020, 02:03:15 am
content: Much to my surprise an email arrived from Siglent that have apparently been following this thread or others have pointed them here, announcing they are to improve SDS5000X measurement count performance in future firmware.

author: tom66
author_rank: Super Contributor
timestamp: March 07, 2020, 01:43:11 pm
content: That’s good to hear. Did they indicate an ETA?

author: tom66
author_rank: Super Contributor
timestamp: March 10, 2020, 10:07:21 am
content: I just received v0.9.0 from the supplier.I can confirm the N pulses bug appears to have been fixed - so well done to Siglent there.Overall the instrument is beginning to grow on me!Sadly it needs to go back this afternoon...

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: March 10, 2020, 01:14:59 pm
content: WowSiglent is even more reactive than the A-brand.I may keep my MSO7000 in the workshop and replace my MSO5000 with an SDS2104x+ at home.Siglent, it is time to send me a nice PM

author: Tom45
author_rank: Frequent Contributor
timestamp: March 10, 2020, 03:47:58 pm
content: Quote from: jemangedeslolos on March 10, 2020, 01:14:59 pmThe SDS2xxx+ scopes are backordered everywhere. At least in the U.S. I just tried to order a SDS2104x+ myself.

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: March 10, 2020, 04:03:24 pm
content: Quote from: Tom45 on March 10, 2020, 03:47:58 pmThere is at least one SDS2104X+ in Germany ( Batronix )