EEVblog #864 - Siglent SDS2000X Series Oscilloscope Teardown  - Page 1
Forum section: electronics / general

author: EEVblog
author_rank: Unknown
timestamp: March 30, 2016, 10:44:42 pm
content: Inside the new Siglent SDS2000X Series 4 channel 300MHz oscilloscope.http://www.siglent.com/ENs/pdxx.aspx?id=1243&T=2&tid=1Datasheets:Micron DDR3 SDRAMhttps://www.micron.com/~/media/documents/products/data-sheet/dram/ddr3/2gb_ddr3_sdram.pdfNetsol SRAM:http://www.netsol.co.kr/upload/f_prod/S7R16xx82M_rev1.3(4).pdfADCMP562 Comparatorhttp://www.analog.com/media/en/technical-documentation/data-sheets/ADCMP561_562.pdfTrio Test:http://www.triotest.com.au/shop/

author: Towger
author_rank: Super Contributor
timestamp: March 30, 2016, 11:28:12 pm
content: Will it have their signature rust... Time to start watching...

author: SAI_Peregrinus
author_rank: Contributor
timestamp: March 30, 2016, 11:55:50 pm
content: No rust. It may have been purely cosmetic but getting rid of it does show an increased attention to detail.

author: lowimpedance
author_rank: Super Contributor
timestamp: March 31, 2016, 12:48:41 am
content: So each bandwidth model will have those hand soldered parts tweaked, wonder if there would be additional software 'tweaks' too ......hmm.Also looks like the worker doing the hardware part forgot his glasses for this units 'tweaks' !!.... rough as.Otherwise looks like a decent unit.

author: grouchobyte
author_rank: Regular Contributor
timestamp: March 31, 2016, 12:58:59 am
content: Nice teardown, Dave! Sigilent has come a long way since their first entry into the market. At their current pace, they might even overtake Rigol or at least put a dent in Rigol sales.Now that the teardown video is recorded and uploaded for posterity, I think its time for....http://www.willitblend.com/(Dave, just kidding,...... I know its a loaner and that might irritate your local T&M benefactor)

author: bktemp
author_rank: Super Contributor
timestamp: March 31, 2016, 05:50:52 am
content: Did anybody noticed the unsoldered pins at each corner of the ADC? Why did they do that? It looks pretty risky, because they can bend easily and short together. One pin seems to be soldered onto the pad from R189 next to it, so I hope those pins are internally not connected.Maybe the ADC being used is a different one than the board was designed for?Does it really help to put a heatsink onto the front of an IC or transistor package or does it only fool the temperature measurement to make you thinking it helps?The plastic material has clearly a much higher tehermal resistance than the metal plate at the back, so I don't think it really helps much, especially when it is mounted without much thermal contact like the one in the picture.

author: LPaul
author_rank: Contributor
timestamp: March 31, 2016, 11:14:35 am
content: They share some engineers with Yahol for the PLL apprently?

author: qno
author_rank: Frequent Contributor
timestamp: March 31, 2016, 11:40:19 am
content: Hi Dave,Watched your video..I am a bit confused about the last 20 seconds or so??

author: rsjsouza
author_rank: Super Contributor
timestamp: March 31, 2016, 07:19:53 pm
content: Good teardown, Dave. Your urge to start playing with the scope during the making of this video is hilarious!Interesting in the picture sent by bktemp: Siglent does the same mistakepointed by Budin page 3 of <Project Yaigol part 2_2.pdf>: both L39 and L40 should have been placed 90° apart.

author: rf-loop
author_rank: Super Contributor
timestamp: April 01, 2016, 09:03:14 am
content: Quote from: bktemp on March 31, 2016, 05:50:52 amPerhaps something like this.LQFP144 where corners have 4 pins N.C.

author: tszaboo
author_rank: Super Contributor
timestamp: April 01, 2016, 02:24:52 pm
content: Quote from: Towger on March 30, 2016, 11:28:12 pmYes, lets make a timelapse video showing the Siglent rust. It will be as interesting as watching paint dry or grass grow!

author: bitwelder
author_rank: Super Contributor
timestamp: April 02, 2016, 08:19:33 am
content: The missing 'Warranty void' sticker might be a sign that somebody did check before sending a rusty unit to Dave...

author: bktemp
author_rank: Super Contributor
timestamp: April 02, 2016, 08:40:43 am
content: All the metal looks like aluminium, so you won't see any rust.

author: rf-loop
author_rank: Super Contributor
timestamp: April 02, 2016, 09:04:15 am
content: Quote from: bitwelder on April 02, 2016, 08:19:33 amInternal chassis is aluminium.

author: ghulands
author_rank: Contributor
timestamp: April 02, 2016, 11:39:13 pm
content: Dave,When do you think you'll have a review video of the scope up?

author: rf-loop
author_rank: Super Contributor
timestamp: April 03, 2016, 08:04:41 am
content: Quote from: ghulands on April 02, 2016, 11:39:13 pmDo not hurry. Imho it is better to wait enough so that he can first really study how to use oscilloscope right and after then do review. Least for avoid basic errors what easy happened as we can see example with SDS1000X. First there need study and learn and get experience. After then to show. If do it opposite order... well, if it is just for entertaintment show, noobs may admire and applause but professionals may feel the shame, exept if it is some kind of satire.Also, I like to know if this individual scope is from "sellers demo" lot or if it is after then manufactured normal production for public sell what may have less reworked main board (example).(it is possible that "sellers demo" units manufacturing lot have some exeptions, perhaps some units opened many times in factory and done some adjustments as component level changes. Least I can see it clearly if I look SDS2304 previous "sellers demo" unit and its internals.) Perhaps Dave can ask this question from source of this individual scope.

author: coppice
author_rank: Super Contributor
timestamp: April 03, 2016, 02:25:43 pm
content: ADDA fans are used in Cisco and Sun systems. They certainly aren't the bottom of the barrel.Why was Dave making fun of pop rivets in an aluminium chassis? That's usually considered a pretty respectable construction method.

author: SeanB
author_rank: Super Contributor
timestamp: April 04, 2016, 06:54:40 pm
content: Rivets are a high cost manufacture option, and if you are going for a higher volume you will use a spot welder to do this join instead. Hopefully they did not use a rivet that has a mandrel, as those often can work loose with time. Not good to have floating loose inside equipment.

author: tautech
author_rank: Super Contributor
timestamp: April 05, 2016, 09:03:17 am
content: Quote from: SeanB on April 04, 2016, 06:54:40 pmMuch, much less so for aluminium rivets compared to steel rivets where as you say, it is not uncommon.

author: lpc32
author_rank: Frequent Contributor
timestamp: April 05, 2016, 12:33:02 pm
content: Is there not enough solder there? The resistor to the left, the one in the center, the blue MOV (or capacitor?)...

author: nctnico
author_rank: Super Contributor
timestamp: April 05, 2016, 12:38:52 pm
content: That PSU has a few things to complain about. I agree they could have soldered it better so the tin would fill the holes all the way for better long term mechanical stability. Also that heatsink glued on top of U9 is not going to do much at all. Judging from the pads they initially went for an SMT heatsink but the capacitor to the left may be too high for the SMT heatsink to fit.

author: lpc32
author_rank: Frequent Contributor
timestamp: April 07, 2016, 06:19:04 pm
content: I recently saw similarly underfilled holes in a new audio amplifier.Are these thruholes soldered manually? Is it a common manufacturing problem?

author: tautech
author_rank: Super Contributor
timestamp: April 07, 2016, 06:27:50 pm
content: Quote from: lpc32 on April 07, 2016, 06:19:04 pmI wouldn't of thought so, but until the underside of the PCB can be seen who know how little or much solder is there.The PCB will have been visually inspected of course.

author: analogNewbie
author_rank: Regular Contributor
timestamp: April 09, 2016, 12:52:53 am
content: I am wondering if this family share the same hardware.

author: tautech
author_rank: Super Contributor
timestamp: April 09, 2016, 01:24:36 am
content: Quote from: analogNewbie on April 09, 2016, 12:52:53 amAFAIK they surely do, however the 2 channel versions are without some front panel HW and the main PCB will be only populated with enough componentry to support those 2 channels.

author: analogNewbie
author_rank: Regular Contributor
timestamp: April 09, 2016, 02:39:33 am
content: Quote from: tautech on April 09, 2016, 01:24:36 amGood. I should take a look at the firmware to see what I can do before spend the money.

author: rf-loop
author_rank: Super Contributor
timestamp: April 09, 2016, 09:06:22 am
content: Quote from: analogNewbie on April 09, 2016, 12:52:53 amIf look SDS2072X to SDS2304X there is same HW (exept possible small component value differencies in analog front end)As tautech tell in 2 channel models they can leave some areas without components. It is much more expensive to produce different boards to different versions.But then you show your location is in China.There situation is bit more "complex"There you have more models in SDS2k series.You have there full set of these all modelsSDS2000 28M(?) memory, 8bit LA (perhaps this 28M is obsolete info and also this have now 70M memory for both 2 channel group also in china version?)SDS2000X-E 70M memory,no LA and less memory(memory is 70M for both two channel groups. So 4 channel have 70+70M)SDS2000X 140M memory, 16bit LA (memory is 140M for both channels group, so 4 channel model have 140+140M)

author: tautech
author_rank: Super Contributor
timestamp: April 11, 2016, 09:16:17 am
content: New FW for the SDS2000X series:http://www.siglentamerica.com/USA_website_2014/Firmware&Software/firmware/SDS2000X-P33R1.rarFrom the website changelog:1. Improved the user experience on the universal knob2. Added virtual numeric keypad function in cases inputting large number is possible (push the universal knob to call it)3. Optimized the persistence display in pass/fail mode4. Added ASCII decoding5. Fixed some bugsa) Pushing the trigger level knob in AC coupled trigger mode does not bring the level back to zerob) Value jumps up and down when setting baud rate in trigger settingc) Arrow in decoding list displays abnormallyd) Digital channel display probleme) All frames are not mapped to the display in sequence mode with frames quantity > 1024

author: F5D
author_rank: Newbie
timestamp: April 11, 2016, 06:22:46 pm
content: I am also eagerly waiting for reports how the 2000X is doing with the new firmware. Does the ERES work? I read from the v2 firmware thread that it does not do anything in the case of the sds2000. If the ERES works and if the FFT mode was a little bit better implemented, I would be all over this at this point, especially due to the discount campaign, but now waiting a little bit before deciding which way to go. Also, would be nice to have png or jpeg screencap instead of bmp.Actually, what are the differences between the sds2000 and sds2000x regarding software and functionality? Regarding hardware, I noticed they moved the trigger level knob further away from the intensity adjust knob, good move.

author: rf-loop
author_rank: Super Contributor
timestamp: April 12, 2016, 10:28:51 am
content: Quote from: F5D on April 11, 2016, 06:22:46 pmSDS2000 have 70M memory for 2 channel and 2 x 70M for 4 channel.SDS2000X have 140M memory for 2 channel and 2 x 140M for 4 channel.SDS2000 have 8 channel LASDS2000X have 16 channel LAFront panel/UI useability is better in X model. (There is several changes)I have not tested 2000X but what I have discussed with Siglent there is also some improvement in analog front end.-------------ERES works in SDS2000.I will later show some images and some data after I have enough time for do this.I hope they never add jpg saving. Imho, png is much better. (jpg is not good for tekchical images where is details, it is well ok for usual photographs.) At this time, irfan view and batch conversion if more than just pair of images.

author: rf-loop
author_rank: Super Contributor
timestamp: April 14, 2016, 06:59:33 am
content: Quote from: F5D on April 11, 2016, 06:22:46 pmThere are rumors and beliefs - whether intentionally or unintentionally. Sometimes, it may also be the case whether the person does not know how to use the device, or that do not understand what a function is. As in the past, for example with regard to the SDS1000X Dave went completely confused when he introduced the sequence mode in ranting video aka "rewiev". (or was it lesson: "do not abuse scope")These tests are from older FW 1.02.01.01.28R1(new FW is 1.2.1.1.3301)NOTE: because this topic is about SDS2000X need emphasize that this my test is made usingSDS2000.I can not guarantee SDS2000X is exactly same if do exactly these same testsIn images a to i signal is same. In image k signal externally combined noise is removed and frequency changed but sine level to scope is still 600mVp-paimage a is just normal mode with full 2GSa/s samplerate. 1 channel in use.Signal is 16kHz sinewave where is also added gaussian noise ~0 to ~80MHz (two signals, sine and noise, combined before scope input)Wfm/s speed is around 970 wfm/s. No detectable difference if use dots or lines and/or sinc on or off or persistence.(in this image: lines, sinc on, persitence off)bsame normal mode as a but samplerate dropped to 100MSa/s (14k memory. In Siglent, whole memory in use is always mapped to display, not overlapp)Wfm/s speed is now ~2900. No detectable difference if use dots or lines and/or sinc on or off or persistence.(in this image: lines, sinc on, persitence off)csame as b but mode is PeakDetectWfm/s speed is now ~2900 as also in b. No detectable difference if use dots or lines and/or sinc on or off or persistence.(in this image: lines, sinc on, persitence off)d, e, f, g, h, isame as b exept now mode is ERES 0.5/1.0/1.5/2.0/2.5/3.0Wfm/s speed is now ~ 7* No detectable difference if use dots or lines and/or sinc on or off(in this image: lines, sinc on, persitence not selectable)* this is for 10us/div ERES.kSignal 700kHz pure sinewave 600mVp-p where can see -3dB drop.Ref level 0dB as 16kHz sinewave.(if drop samplerate to 10MSa/s and keep ERES3.0 then (just math) -3dB points also drops to 70kHzIf 100MSa/s and change ERES 3.0 to ERES 2.5 then -3dB points move to 1400kHz ... and so on...)

author: nctnico
author_rank: Super Contributor
timestamp: April 14, 2016, 08:37:39 am
content: Two questions:- Can you zoom in vertically on the Eres signal so you can use the extra resolution to see more detail?- Is the Eres still limited to only 14kpts of memory depth (aka a checkbox feature with no practical use)?

author: rf-loop
author_rank: Super Contributor
timestamp: April 15, 2016, 07:34:54 am
content: Quote from: F5D on April 11, 2016, 06:22:46 pmIntensity adjust knob/multifunction knob. Nearly all parameters need set with this knob. It was previously frusttrating to turn this knob minutes until reach wanted value. If need turn from 0 to 10000 it takes time. Even when there is some acceleration. In some cases also this affect so that fast turning and oops, then after long time you jump over wanted, then back and agen over... exept if do it carefully. Problem with SDS2000 is that it is too close trigger level knob. If y turn multifunction knob and just finger accidentally touch trigger level you jump out from this parameter setting what you was doing. It was mandatory change what they do for SDS2000X. Also in control panel there is some other good changes.But now, with new FW multifunction knob different, there is new feature. With some function where need set some value using this multifunction knob user can push it and get small virtual numeric keyboard on the screen. Using this user can fast select exact value.. Of course if there is hardware numeric keyboard it is super good but also this virtual is better than nothing.

author: Hydrawerk
author_rank: Super Contributor
timestamp: April 15, 2016, 06:30:11 pm
content: I am looking forward to Dave's review of SDS2000X.

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: May 02, 2016, 06:39:06 pm
content: Is there a dedicated thread for the SDS2000X? I recently bought one, and would like to list out a couple of issues I came across in the hope that Siglent would address them in future firmware updates.Quick example: the waveform update rate is dramatically reduced when signal measurements are enabled. You can see the trigger status indicator flashing between ARM and TRIG'd when measurements are enabled.

author: nctnico
author_rank: Super Contributor
timestamp: May 02, 2016, 06:44:56 pm
content: Quote from: radar_macgyver on May 02, 2016, 06:39:06 pmI already went down that roadand ended up losing my money on a useless scope. Seriously: just send it back if it doesn't do what you need because hoping Siglent will solve any issue (quick or at all) is just as useful as hoping Christmas and Easter will happen on the same day.

author: tautech
author_rank: Super Contributor
timestamp: May 02, 2016, 08:06:15 pm
content: Quote from: radar_macgyver on May 02, 2016, 06:39:06 pmNot as yet.QuoteHere's as good as anywhere.QuoteAt what timebase and other settings?

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: May 02, 2016, 08:46:59 pm
content: Quote from: tautech on May 02, 2016, 08:06:15 pmI started at 100us/div, and 14k memory depth, CH1 enabled, all others off. Memory depth is set to 14k. I hooked up the TRIG OUT to my other scope to try to make sense of what's going on. It seems like its not the update rate, but the dead time that changes. And it doesn't change in a way that makes sense. Under the scope setup listed above, I could see that the dead time without measurements enabled is about 3 ms. Changing the input waveform caused the display to update virtually instantly.With measurements enabled, dead time jumps to over 40 ms, and the waveform on screen appears to lag the changes in input. I mistook the lag to mean lower update rate. Still, it's very disconcerting to see.Now, the strangest thing is that when I enable channel 2 (which shares the ADC with channel 1), the dead time once again drops to ~3 ms.Fiddling with other settings such as memory depth caused some other weirdness to show up in the dead time. For example, at 140k memory depth, the scope does two bursts of acquisitions, then waits for nearly 120 ms (!) before doing another pair. Note that the horizontal timebase (on the 54602B) was doubled for this image.It almost seems like the scope is trying to sync together several different internal processes to generate the display, and that the process that handles the measurement computations is holding up everything else, including acquisition. The fix would be to decouple these, at the risk that you may have measurements that don't match what the scope is currently displaying.edit: added inline images.

author: tautech
author_rank: Super Contributor
timestamp: May 02, 2016, 09:02:29 pm
content: The FW version that you're using may have something to do with this.Latest:http://www.siglentamerica.com/USA_website_2014/Firmware&Software/firmware/SDS2000X-P33R1.rarrf-loop discusses the changes in latest FW and trig-out waveforms:https://www.eevblog.com/forum/testgear/siglent-sds1000x-series-oscilloscopes/msg920943/#msg920943Sure it's not the same scope but the FW is very similar.More reading:https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/Members Performa01 or rf-loop might have further explanation.

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: May 02, 2016, 09:17:35 pm
content: Ah yes, should have mentioned - I did grab the newest firmware available from Siglent, put the .ads file on a USB stick and went through the upgrade procedure. Not sure if it was needed, but there's no easy way to tell since the firmware version page indicates the version numbers of all the individual components inside the scope, but not the overall firmware update file name.@Siglent: this would be a nice, easy thing to fix, either (1) name the update files to match the numbers shown in the scope, or (2) have a line shown on the scope indicating the overall firmware revision, in addition to the FPGA versions, etc.

author: tautech
author_rank: Super Contributor
timestamp: May 02, 2016, 09:38:52 pm
content: Further explanation of your observations are made in this post;https://www.eevblog.com/forum/testgear/siglent-sds1000x-series-oscilloscopes/msg926963/#msg926963The acquisition process is outlined and use of dots is recommended to maximise update rates.Quote from: radar_macgyver on May 02, 2016, 09:17:35 pmCould you elaborate more on this ^Pics?

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: May 02, 2016, 10:30:52 pm
content: Quote from: tautech on May 02, 2016, 09:38:52 pmWhen I go to Utility->System Status, I can see the following:Software version: 1.2.133.1FPGA version: 16.1.29Hardware version: 6-4Serial numbers, etc.When I go to Siglent's website, I download a file called SDS2000X-P33R1.rar. From these two bits of information, how can I tell that I have the latest firmware installed? Either Siglent should name the file something like SDS2000X-1.2.133.1-16.1.29.rar, or have an additional line in Utility->System Status that says Firmware Revision: P33R1.Unless, of course, it's already listed and I missed it.As for the update rate maximization, yes, I had read that thread. I don't think that what I'm seeing is desired behavior, though. It seems highly unlikely that a ~600 MHz Blackfin processor would take 40-3 = 33 milliseconds to compute the peak-to-peak voltage and time period for 14k samples, this seems like it was implemented incorrectly.

author: tautech
author_rank: Super Contributor
timestamp: May 03, 2016, 04:15:08 am
content: Quote from: radar_macgyver on May 02, 2016, 10:30:52 pmYou did sort of, see bold highlights ^^^QuoteI do wonder if you have other features enabled that has slowed the update rates to a point where it is noticeable?Try a "Default" to disable all settings not necessary and see if your noticed behaviour remains.There's further recent discussion here:https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/msg923035/#msg923035Anyways, Siglent tech support have been linked to your posts.

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: May 03, 2016, 05:01:05 am
content: Quote from: tautech on May 03, 2016, 04:15:08 amLol, not the most obvious, but yes, it is there once you know what to look for.Quote from: tautech on May 03, 2016, 04:15:08 amThe discussion on that thread seems to focus on the sequence mode, which I'm not using. I repeated the test after pressing "Default", the only settings changed after that are the trigger level, vertical and horizontal scale, and the acquisition settings as described in my previous post.Quote from: tautech on May 03, 2016, 04:15:08 amThank you much! Hopefully they'll figure out what's the cause.

author: rf-loop
author_rank: Super Contributor
timestamp: May 03, 2016, 08:49:36 am
content: Here how it looks with SDS2000 without X.Measurements and tracking cursors and if measurements are Gated or not, do not affect in this test.If shut off measurements result in trig out is exactly same or least I can not detect difference.But, I can believe X model may have some bug there.Just noted this also in some caases with SDS1kX with version P06SDS2304 all meas and tracking curs on and measurement mode gated and statistics also on.Here what it looks from SDS2304 Trigger Output using SDS1202X for monitoring.SDS1202X-S Signal from SDS2304 Trig Out (previous image situation)Result: No any slow down nor does anything strange noticeable in acquisition cycle when use cursors and measurements things in SDS2304. Just rock solid.

author: tautech
author_rank: Super Contributor
timestamp: May 03, 2016, 09:59:21 am
content: Quote from: rf-loop on May 03, 2016, 08:49:36 amTech support confirms your X series suspicions and radar_macgyver's findings and it's been passed to R&D.We'll keep you all informed.

author: rf-loop
author_rank: Super Contributor
timestamp: May 03, 2016, 10:33:03 am
content: Quote from: tautech on May 03, 2016, 09:59:21 amTNX. I heve been just thinking that I will made further tests with SDS1kX and report to Siglent but, due to lack of time and other work with SDS1000X Wavegen this issue have been waiting. Good to know issue is delivered to Siglent. (I was thinking to give bit more detailed information to Siglent but lets hope theu find themselves enough - lets hope there is some who is enough calm and circumspect for do careful tests so that it is fully analyzed first all what conflict there and only after then take FW on the table for stop oops...oops...oops... rounds.

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: May 04, 2016, 04:16:44 am
content: Thanks, tautech! Please let me know if there's any additional info I can provide.

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: May 04, 2016, 05:21:54 am
content: Another bug to report: the display persistence doesn't really behave properly. I expected that if the persistence is set for, say, 5 seconds, and a random pulse shows up on the display, it will stay on the display for 5 seconds before disappearing. Instead, the firmware effectively implements infinite persistence, and clears the persistence once every 5 seconds. This is not expected behavior and makes the timed persistence function mostly useless.Additionally, when the persistence menu is set to 1s, it never clears the display (same as infinite).Also, the way the persistence works is a bit odd. The historic data is shown at 50% intensity, and after the timeout it disappears immediately. IMO it is preferable to fade out the historic data gradually, like the Tek DPO series does. The same hardware in the display processor FPGA that handles intensity grading can accomplish this easily.

author: rf-loop
author_rank: Super Contributor
timestamp: May 05, 2016, 08:05:57 am
content: Quote from: radar_macgyver on May 04, 2016, 05:21:54 amStrange. But agen, I do not have SDS2kX, I have SDS2k and SDS1kX.Just tested with SDS1000X and Persistence works. When scope running (using gaussian noise as signal) whole time new samples are hold on screen until time limit and older shutted off from image, continuously just like fifo works.QuoteWhat additional information this slow fade out give to user? Or do you mean it is cosmetically more "nice".Fast acquisition and image daata processing is bit time critical process. I do not accept if example persistence on slows wfm/s speed. If we need keep track for every acquisition age it is bit hard. If there is example 100000 wfm/s there is roughly 4000 acquisitions in each TFT image what are renewed every 40ms with new set of 4000 acquisitions. This is still quite easy case but when we work with random undefined signals scope can not design just for one case, sontinuous repetitive signal. Before this fade out gradattion is good we need time stamp every single acquisition and after time start decay intensity individually for every acquisition. If we now want 5 second persistence and after then say example 5s fade out. Total time for every acquisition is 10s and in "worst" case there is now 1000000 acquisition in ageing queye.Easy case if there is 100wfm/s acquisition speed. Bit harder if 1000 times more or even more.If do not want this perfect system what may be useful in some cases if also user can adjust these keep and fadeoff parameters for his signal inder test, in some cases I can see it may give some kind of advantage over "only nice image".More easy it is if we want only just cosmetically "nice image" it can do more easy. But I can not see how much it really give added value. Oscilloscope, as caar and as camera is always compromise, add something and perhaps loose something like car tires, get more longevity - get more slipery in wet.Get more nice image and it (may) need more processing force what may need take from some other place just when there is critical need for all possible resources if do not add more brute force in HW.Let us wish that the development is developing.

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: May 06, 2016, 05:55:59 am
content: Quote from: rf-loop on May 05, 2016, 08:05:57 amThe fade part is just eye-candy. Well sort-of, I'll get back to that. More important, though, is the "FIFO" behavior you described earlier. Right now, the scope behaves like it has infinite persistence, and someone pushed "Clear Persistence" every 5 seconds. For example, if the scope auto-clears the persistence, and four seconds later a jitter event or runt pulse shows up, it will only stay on screen for 5-4 = 1 second before it is auto-cleared on the next cycle. This doesn't present the same information as true FIFO persistence would.As for the fade-out, it does help to determine the frequency of occurrence of an event shown on screen. For example, let's say we have a runt pulse occurs once every 3 seconds, and a different runt pulse occurs once every 10 seconds. With the scope set for 10 second persistence, the first runt pulse will appear brighter on screen than the second one. This is how I've used the DPO capability of a Tek scope. Granted, there are other ways to accomplish the same thing, I'm saying that this should be easily achievable with their current display processor hardware. This would fall into a "nice to have" feature. The first part about the way persistence behaves on the SDS2000X is definitely a bug, though.Quote from: rf-loop on May 05, 2016, 08:05:57 amDoesn't have to be done this way. This can be simulated by applying a periodic "decrement" to all the intensity values stored in display RAM. Let's say, for example, we have a 512x512 frame buffer. The display processor FPGA already implements writing (optionally with interpolation vectors) data into the frame buffer, likely using a 'saturating add' raster op (this is how it does intensity grading). Each refresh cycle of the TFT, this frame buffer gets cleared.To implement fade-out and persistence, don't clear the buffer. Instead, once everynframes, decrement the intensity value of each pixel in the buffer. If it reaches zero, stay at zero (saturating subtract). By changingn, one can achieve various different fade-out rates, corresponding to different persistence times. Even if done in software, this would only take 512x512x2/n= 524288/noperations (compare/branch, decrement) per frame. In practice, this is better handled by the display processor FPGA. If you want to be super-slick, integrate this function into the display DRAM refresh cycles and the operation becomes "free".Hmm... this almost sounds like something one would do with a GPU. Maybe in the SDS3000?

author: rf-loop
author_rank: Super Contributor
timestamp: May 06, 2016, 04:53:05 pm
content: Quote from: radar_macgyver on May 06, 2016, 05:55:59 amThis must be The Bug. Example SDS1000X do not work like you tell. If there is example 1s or 5s persistence... whole time there come new pixels and continuously same time old pixels shut off like continuous process. I do not know if ageing resolution is 1 image refresh or what it is but with eyes looks quite smooth.(I know what you mean with this reset and start new 5s collecting and after 5 sec all of and new turn. This is absolutely wrong = must be bug.)

author: Unknown
author_rank: Unknown
timestamp: May 09, 2016, 12:12:24 pm
content: Good morning.This is a bug that had been found earlier. It has been fixed in a new update and is currently undergoing testing at the factory.Steve

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: May 12, 2016, 06:06:55 pm
content: Quote from: radar_macgyver on May 06, 2016, 05:55:59 amThe SDS3000 has proper DPO-like persistence mode (including the fading bit) and had it right from the start. But then, the software in that scope isn't from Siglent (only the hardware is), which means it also came to market without major bugs (and just a few minor ones)

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: May 19, 2016, 03:25:11 am
content: Another bug to report: serial protocol decode (well, at least UART decode) seems to stop working when digital channels are enabled. Note, this happens even when the protocol decode input is set to one of the analog channels; simply having the digital channels on screen messes up the protocol decoder.The protocol decoder seems to work only when the beginning of the serial frame is visible on screen, even when the Zoom feature is used (ie, the acquisition hardware has captured enough samples to perform the decode, but only some are shown on screen).

author: tautech
author_rank: Super Contributor
timestamp: May 19, 2016, 03:43:16 am
content: Quote from: radar_macgyver on May 19, 2016, 03:25:11 amJust trying to get my head around your findings.Have you read this post:https://www.eevblog.com/forum/testgear/siglent-sds1000x-series-oscilloscopes/msg920669/#msg920669Sure it's not with the digital channels but if you study the images there might be some clues as to what you're seeing.Trigger settings have a lot to do with successful decoding.Can you post up some screen captures?

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: May 19, 2016, 04:25:11 am
content: OK, the first part of my bug report seems like it may have been user error (aka, I was dumb) - I couldn't replicate it after I had made some changes to the arduino code I used to generate the serial test data.The second part (only showing the decoded data when the beginning of the frame is visible) is illustrated below. In the first image, I have zoomed in such that the start bit of the first character ('6') is on screen. Everything works as expected. In the second image, I scrolled the zoom area so that the start bit of the first character is off to the left of the screen. The decoded data is blank, even though there are several valid characters displayed.rf-loop had earlier reported that the scope must trigger on the data for the index shown in list mode to be accurate, but he explicitly mentioned that the decode still works in this condition (on an SDS1000X). This lets you capture a bunch of data, then zoom in and scroll around to read the contents. It seems to not be the case for an SDS2000X, as soon as you scroll so that the beginning of the data is off-screen, decode disappears.

author: tautech
author_rank: Super Contributor
timestamp: May 19, 2016, 05:06:30 am
content: Quote from: radar_macgyver on May 19, 2016, 04:25:11 amWhen decoding with analogue while the digital channels are enabled......right?I'll point Steve @ Siglent USA to this to see if he can replicate it. (not got my 2000X yet to try with.)QuoteThe difference between rf-loops and yours are the trigger settings vs the edge of the first bit. Is it different with a falling edge trigger?

author: rf-loop
author_rank: Super Contributor
timestamp: May 19, 2016, 08:40:45 am
content: This is how it works inSDS1000X!I do not know how it is in 2000X.1.One transmitted whole string. All is decoded and in table there can scroll and read. (if there is error, bottom blue line have red marks where is error)2.Window zoom, scope running and new frames capturing all time. (I send repeating same string)3.4.5.After captured as in image 1. or 3.There can also stop and zoom in full window. But, I hope improve FW so that user always know data byte count from trigger (and in window zoom also same)Also without zooming, when there is just example image 1. and user search list to some position in frame there need be visible indicator what show list cursor position on the signal trace. Also if hope bit more, there can be user defined example 2-12 sequential character string with boolean so that scope can find this (or these) user defined exist.(Image bottom orange arrow direction is wrong, it need bend to bottom left corner)

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: May 20, 2016, 05:34:35 am
content: Quote from: tautech on May 19, 2016, 05:06:30 amAfter posting I noticed I was triggering on rising edge. Behavior remains the same with falling edge triggering as well - as soon as I zoom and pan the left edge of the data off screen, the decoded output changes to a flat blue line (which means line idle, I think). One more difference is that the baud rate I used on my tests is 115200 baud. I re-tested at 9600 baud with the same results.@rf-loop: Understood. It seems like my 2204X does not behave the same way.@tautech: Thank you for reporting to Siglent. Hopefully they'll get the issue solved. In the meantime, the scope seems to do most basic stuff just fine. I'll keep exploring the fancier features and let you know if I came across something weird.If I may, a 'minor annoyance' is that the scope re-arms itself too quickly in auto mode. During these tests with the serial decoder, I had an arduino output a burst of characters once a second. With the trigger set to auto, I would often not see anything on screen, even though the scope indicated it was triggered. I had to switch to Normal mode before I could get the display to show me something. I would have preferred if Auto trigger mode held data on screen for a little longer, before re-arming the trigger.

author: tautech
author_rank: Super Contributor
timestamp: May 20, 2016, 06:18:13 am
content: Quote from: radar_macgyver on May 20, 2016, 05:34:35 amAs with any perceived problem it's great if you can post some supporting screenshots that we can point Tech support to.It's so much easier then to duplicate your findings as there's much info in a screenshot that then doesn't need mention.Quote

author: rf-loop
author_rank: Super Contributor
timestamp: May 20, 2016, 10:06:17 am
content: Quote from: radar_macgyver on May 20, 2016, 05:34:35 amTry much longer trigger holdoff time. (you need not turn anymore multifunction knob "endless" for adjust it much higher value. Push knob and use virtual keyboard.)Scope default holdoff need be short, other way we read thousends of negative comments how slow this scope reeact when touch probe to some potential before anything see on the screen. But user can adjust it when really need. (example if you try look AM modulated signal so that you want trig to modualtion freq, this is fast and practical way to adjust holdoff so that get stabile trig.In case where something happends some times and then scope auto trig fast agen and flush old trace out but we want still see it. Persistence is some times useful tool.Have you tried set trigger mode BUS and then set all trig paramaters for UART?

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: May 21, 2016, 04:38:26 am
content: Quote from: tautech on May 20, 2016, 06:18:13 amI agree. In this case, though, a screenshot wouldn't help since it's a *time* effect. Instead, I'll do what the cool kids are doing these days and post some videos. Please forgive my lack of skill. In all cases, I used the internal waveform generator to produce a 1 Hz pulse, with 50 us pulse width.Playlist with all the videos:https://vimeo.com/album/3960396Video 1 is in Auto mode, with ~800 ms holdoff as suggested by rf-loop:First, every pulse that's displayed has trace data at zero volts everywhere. My interpretation of this is that the scope re-arms itself almost instantly, and tries to display the trace when it's at zero volts. Even worse, the scope seems to trigger, but displays no pulse. For example, at 2 seconds, and then again at 7 seconds. This is bizarre, there should have been one trigger per second.Video 2 is in Auto mode, with no trigger holdoff:Here, the scope seems more eager to trigger but not display anything. You can see it happen at the 1 second mark, and then again at the 7 second mark. I couldn't catch it doing so on camera, but on occasion I would see the pulse on screen get mangled - the width would be something completely different from 50 us.In, video 3 is with the scope in normal trigger mode:This is what I expected to see. I found that I had to set the waveform generator frequency as high as 8 Hz before auto and normal trigger modes showed the same thing on screen. This means that the re-arm time in auto trigger mode is something less than 0.125 seconds. I think this is too short - it ought to be at least a half second so that the waveforms shown on screen in auto trigger mode can actually be seen. After all, that's the whole point of auto trigger mode - to explore around without knowing what sort of signals to look for.Finally, here's the same signal on ye olde 54602B:This scope had the holdoff set to 800 ms as well. It never misses any pulses, and you can clearly see the structure of the pulse. It's misshapen since the probe compensation wasn't adjusted. Due to the large dead time that its acquisition system has, it performed poorly with the holdoff turned down.Quote from: tautech on May 20, 2016, 06:18:13 amJust in case my point got lost - the scope behaved the same whether I was triggering on the rising or the falling edge.Quote from: rf-loop on May 20, 2016, 10:06:17 amAs I noted above, the issue at hand is not fixed by increasing holdoff.Quote from: rf-loop on May 20, 2016, 10:06:17 amIf you're referring to my previous post about the serial decoder, it should not matter how the scope acquisition is done. My point is that as soon as the first transition of the data is moved off-screen, the decoding fails. This prevents me from acquiring a burst of serial data, and then zooming in to look at the details.

author: rf-loop
author_rank: Super Contributor
timestamp: May 21, 2016, 09:01:39 am
content: Because it seems that when I talk many separate things in same msg it leads to confusion.Now I talk only and alone Auto trigger, Trigger holdoff and oscilloscope acquisition speed things. Not Decode or serial trigger.HP54602B is very slow. Nearly like if you set Siglent acquisition to slow mode (not exactly)I have not anymore any 54600 scope here so I can not test its Auto mode free run speed and Trig holdoff.But you show there is 800ms Trig holdoff and you get stabile auto mode trig to 1s period 50us width pulses.I test it with SDS1000X and SDS2000In this particular case, 1s period, 50us width pulse, trigger rising edge, mode Auto. Horizontal speed 10us/divI set Trigger holdoff 950ms (SDS1kX) and 960ms (SDS2k).I run it using pass/fail mask test and they trig rock solid without any loosed pulse and without any extra capture.This is faster than old HP and so, this also need more care how to do settings. Also this Auto mode is some amount faster so time gap for adjust Holdoff time is also more narrow. Btw, 200ms is long time.With 10us/div and Trig Holdoff off and trigger mode Auto, SDS2k (not X) free run (no trigs from signal) average speed is around 515 capture/s.Free run (no trigs from signal) with 5ns/div and other settings for max wfm/s and Trigger mode Auto, Holdoff closed. Average >141000 wfm/s It do not wait trigger event in Auto trig mode so long time.. who want scope is more slow.(there is also images from these tests if need including trigger output images)We want fast scope but then we want it is slow?With holdoff around ~960 - <1000ms trigger to this signal is rock solid. We can see it do not wait as long time as old HP what wait least 200ms (as you show). Driving modern fighter need more accuracy with settings than old cessna what can drive with "oops - so what" settings.Attached these mask tests. Also I have carefully looked that it did not loose any single pulse.

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: May 21, 2016, 07:13:40 pm
content: OK, understood. For the record, I had to set holdoff time to about 950 ms before triggering was stable. I suppose it's the problem with "flying Cessnas" for a long time (54602 at home, MDO4000 at work - perhaps these were yesterday's fighter jets?).So to break it down into simple terms for someone like me, was the effect I saw in video 1 because the scope had just done an acquisition prior to the edge of the 1 Hz signal, and the dead time would cause the pulse to be missed?

author: nctnico
author_rank: Super Contributor
timestamp: May 21, 2016, 08:03:07 pm
content: Quote from: radar_macgyver on May 21, 2016, 04:38:26 amI think you can debate forever about this and not reach any concensus. On many oscilloscopes the auto trigger re-arm time is very short so you can immediately see what is going on. Tektronix does things a little bit different though. When in auto trigger mode it will wait for half a second before going back to auto trigger mode after it has triggered on something in a signal. This can be handy but it can also be a nuisance if you just want to check a level and get the noise from attaching the probe on screen instead. Another work around is a dedicated force-trigger button. This way you don't need to switch between auto/normal mode. You can just hit a button to get a trace on the screen when in normal trigger mode.

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: May 22, 2016, 03:45:47 pm
content: Quote from: nctnico on May 21, 2016, 08:03:07 pmDid not know this. Most times I needed to do anything that needed a fast sweep time but with a slow trigger rate (which is pretty much all the time when working with pulsed radars) I always used a Tek. The few times I had to use an Agilent were with much more benign trigger conditions. I quite like that half-second delay, but I can understand that it will get in the way of people who aren't expecting it.Well, at least Siglent has made the trigger mode controls dedicated buttons. Most others bury it under at least one menu.

author: rf-loop
author_rank: Super Contributor
timestamp: May 23, 2016, 08:39:07 am
content: Quote from: nctnico on May 21, 2016, 08:03:07 pmUsing SDS1000X.It looks that this time is very close 99ms - 100ms.With Tek it give more room for signal variations or to user so that example Trigger Holdoff time do not need adjust so careful. With this Siglent it give only 0.1s window for set.It means, example, that if pulse period is 1000ms user need set Trig holdoff between 901ms to 999ms. If time is more short it fall back to autotrig. If time is over, it can not trig all pulses. In other hand if pulse period is variable it do not "accept" more than this ~0.1s variation.What is good, I do not know. This is compromise but is it good compromise, least I do not know. One want more, one want less.I like if there is separate adjustments for both so that I can my self adjust this time (what is good name for this time) and Trigger Holdoff time.----------------------But then other thing what I some times nearly hate.Perhaps some like but I do not.Automatic force to "Scroll" mode.I have not meet this thing so often because it is quite rare I need time base slower than 10ms/div so it have not been problem for me because my typical use is not under 10ms/div.If need often select different t/div between <=20ms/div - >=50ms. It is frustrating. Really!Why I need loose my working time for this stupidity?I do not like this automatic selection.Least I want there is selection in setup menu where I can select how it switch to scroll mode. Auto or Manual.