Siglent SDS2000 new V2 Firmware - Page 1
Forum section: electronics / testgear

author: tautech
author_rank: Super Contributor
timestamp: November 23, 2015, 05:45:31 am
content: Just publicly released today the new SDS2000V2FW:We've had a peek of this new FW a few weeks ago when Siglent offered us a Beta version to appraise.http://www.siglentamerica.com/USA_website_2014/Firmware&Software/firmware/SDS2000-V2.0-1.02.01.01.27.rarFurther update V2 FW 9 Dechttp://www.siglentamerica.com/USA_website_2014/Firmware&Software/firmware/SDS2000-V2.0-1.02.01.28R1.rarFeedback appreciated.

author: tautech
author_rank: Super Contributor
timestamp: November 23, 2015, 06:57:59 am
content: Please note there are 4 steps to upgrade from V1 to V2 firmware, these are outlined in the update instructions that are part of the FW update.First install a .cfg, then reboot.Then the .ads file TWICE with a reboot after each install.Finally a Self cal.Attached is the pdf changelog.

author: CustomEngineerer
author_rank: Frequent Contributor
timestamp: November 23, 2015, 07:31:46 am
content: From the changelog? Somehow the timescale for the digital channels doesn't follow the timescale for the analog channelsI don't have much faith that Siglent can fix something if they don't know how its happening.

author: tautech
author_rank: Super Contributor
timestamp: November 23, 2015, 07:37:02 am
content: Quote from: CustomEngineerer on November 23, 2015, 07:31:46 amReally.It's a description of a bug thats been addressed in this new FW or don't you get that?

author: tautech
author_rank: Super Contributor
timestamp: November 23, 2015, 07:41:50 am
content: Most notable improvement is the increased Memory Depth, from 28Mpts to70Mptsnow in timebases from 5 to 20ms.

author: CustomEngineerer
author_rank: Frequent Contributor
timestamp: November 23, 2015, 08:02:38 am
content: I get that they say it has been fixed in the new firmware. But the fact that they say "Somehow the timescale..." makes it sound like they don't know what was causing the issue. And if they don't know what was causing it then how can they be sure they fixed it? Maybe I'm misreading it or maybe its a translation to english wording issue.

author: analogNewbie
author_rank: Regular Contributor
timestamp: November 23, 2015, 08:45:23 am
content: I checked the Chinese version. It should be 'sometimes'.

author: 9a4wy
author_rank: Contributor
timestamp: November 23, 2015, 11:25:40 am
content: Is the update from V2 beta same procedure??

author: PedroDaGr8
author_rank: Super Contributor
timestamp: November 23, 2015, 01:42:46 pm
content: Quote from: CustomEngineerer on November 23, 2015, 08:02:38 amChinglish is my first and only guess. Otherwise, there would be never a situation where you word it that way AT ALL. If you didn't know the exact cause you would just say "Fixed timescales does not match analog section).

author: tautech
author_rank: Super Contributor
timestamp: November 23, 2015, 07:40:45 pm
content: Quote from: 9a4wy on November 23, 2015, 11:25:40 amAs you are probably aware the Beta did not enable the 70M memory depth so it would be wise to follow the 4 update steps to gain all the new extras.

author: nctnico
author_rank: Super Contributor
timestamp: November 23, 2015, 09:18:47 pm
content: Quote from: CustomEngineerer on November 23, 2015, 07:31:46 amI have a feeling they copied a lot of text from my bug list. The wording in the changelog looks very familiar to me.

author: TheDefpom
author_rank: Frequent Contributor
timestamp: November 24, 2015, 07:38:14 am
content: My scope sometimes locks up and fails to respond to any key presses, I only found this issue recently having finally getting stuck into some troubleshooting trying to repair a fluke 8842a. It seems to happen after its screen saver comes on and I clear it, hopefully the new firmware helps that issue, I might have to load it tomorrow and see how it goes.

author: tautech
author_rank: Super Contributor
timestamp: November 24, 2015, 08:43:29 am
content: Quote from: TheDefpom on November 24, 2015, 07:38:14 amScott, were you running the Beta FW or the V1 FW yours came with?Did you install the last V1 FW?http://www.siglentamerica.com/USA_website_2014/Firmware&Software/firmware/SDS2000-1.01.01.37.9.rarYou do want to install this new V2 FW and get the additional memory depth it offers.

author: 9a4wy
author_rank: Contributor
timestamp: November 24, 2015, 08:52:22 am
content: I had same problem like TheDefpom with FW v1 on both scopes.K

author: TheDefpom
author_rank: Frequent Contributor
timestamp: November 24, 2015, 10:13:03 am
content: Quote from: tautech on November 24, 2015, 08:43:29 amI am still using the original firmware that the scope came with, I will download the latest one now and have a go at upgrading it...

author: 9a4wy
author_rank: Contributor
timestamp: November 24, 2015, 12:13:49 pm
content: Quote from: 9a4wy on November 23, 2015, 11:25:40 amWords from Mr. Wu (SIGLENT CHINA)" A little different.From V1 to V2 you need upgrade the ADS file twice..From V2 beta to V2-27 you only need upgarde the ADS file one timeRest please follow the Update guide document. "

author: cidcorp
author_rank: Unknown
timestamp: November 24, 2015, 05:15:27 pm
content: My upgrade to the v2  firmware from v2  went well (I upgraded the ads twice for good luck). I will get some time in the near future to do a complete check of all features including Digital channels in thenext week. If I find things wrong - I will post a list. 2 minutes after the upgrade I already noticed that the terminology used in theHISTORYfeature - Button that saysList Off/List Onit's label is reversed. I'd assume you push the button that saysList Offto turn the list off, but I have no list present. Pressing it makes the list appears, and button then readsList On, in theory I guess it could mean the text of the button refers to the lists current state... but well I'm starting to babble... and this issue is trivial.I wanted to at least give Siglent afor including a ChangeLog - that is awesome, and helps alot.Chris

author: TheDefpom
author_rank: Frequent Contributor
timestamp: November 24, 2015, 08:08:57 pm
content: I upgraded mine last night, but don't see the new 70Mpts rate, still 28?Ahh, it doesn't use the new one automatically, I had to go in and select it.I notice it also has a 56Mpts at 2.0mS now.

author: timofonic
author_rank: Frequent Contributor
timestamp: November 25, 2015, 01:09:25 am
content: Quote from: nctnico on November 23, 2015, 09:18:47 pmThey are researching, at least. But it's a shame companies are so proud to recognize feedback from third parties. Anyway, they should hire you full-time to fix their scopes.What's your opinion about this update? Does make it reliable in the level of Rigol or better?

author: TheDefpom
author_rank: Frequent Contributor
timestamp: November 25, 2015, 02:59:13 am
content: I used it for about an hour today, no lock ups so far, one slight bug I found was the digital display, when first set to be the "high" display, when changing triggers (I think it was anyway) on ch1 when I went back out it had changed to "med", which is how it used to show it on mine anyway, so I switched it back to high, seems to stay after that.

author: nctnico
author_rank: Super Contributor
timestamp: November 25, 2015, 09:11:13 am
content: Quote from: timofonic on November 25, 2015, 01:09:25 amI have no opinion since I opted to get rid of my SDS2000. I have listed several other complaints (like only decoding what is on screen - which is useless- and making FFT useful) which I don't see in the changelog.

author: cidcorp
author_rank: Unknown
timestamp: November 25, 2015, 03:17:16 pm
content: Just a heads up for anyone considering doing the upgrade. I'm in the middle of trying to determine why my purchased option keysdon't work on the newly upgraded scope.Batronix indicated that the Scope ID might/should have changed after the update to v2 firmware, but my Serial and Scope ID are exactly the sameafter the upgrade. Sadly the newly delivered option serial keys are not working, they (Batronix) are looking into it... I'll update if there is a *real* issue, hopefullysomething simple. But if you are planning on installing any options in the next bit hold off installing the v2 firmware until they are on the scope.Chris

author: nctnico
author_rank: Super Contributor
timestamp: November 25, 2015, 03:24:57 pm
content: In the V1 software you have to select which option you are going to install otherwise the option key doesn't work. For some reason the firmware can't detect what kind of option you are installing

author: cidcorp
author_rank: Unknown
timestamp: November 25, 2015, 03:44:20 pm
content: Quote from: nctnico on November 25, 2015, 03:24:57 pmOMG lol, I'll give that a try... that's funny as hell.Also kinda sad...Chris*** Update: Nope this made no difference, I would have felt like an idiot.

author: tautech
author_rank: Super Contributor
timestamp: November 25, 2015, 07:14:19 pm
content: Quote from: cidcorp on November 25, 2015, 03:44:20 pmSorry, I haven't got any magic to offer you.All I can suggest is to double check the SN and ID #'s you sent for the option code were correct.The "enable" codes you got back should look something like this: xxxx-xxxx-xxxx-xxxx and there be one for each option acquired.When you enter your codes do you get any indication of error or confirmation of entry?Little walk through:In the OptionInformationwindow there will be a box listing all 4 options and their current status; Trial, Expired or Permanent and when an Option is installed correctly the License Type will bePermanentand the trial counter (Remain Times) will showXXThe options NOT permanently enabled will be highlighted in the OptionTypepopup and the "installed" options not highlighted.As each Option is selected in the Type popup the 2nd window will displayInstallorInstalledas another indicator of the Options status.Option enable codes are entered in a popup window afterInstallis selected for each option NOT installed.

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: November 25, 2015, 07:53:57 pm
content: OK, so I finally had a chance to give this new firmware a spin on my SDS2204. The latest v1 update was pretty much crap and the typical bugfest we've come to expect by now, so it ran the v2 beta which seemed to be more stable than the v1 mess, plus it has a much more logical UI (although there's still room for improvement).It's of course great that Siglent has (for the first time!) kept its promise to come up with the v2 release firmware by the end of NovemberHowever, as with pretty much any firmware Siglent has come up with for the SDS2000, this one seems to suffer from silly bugs, too. I played with the scope for roughly an hour including the upgrade processes, and immediately found two.The first one appeared after calling up the Acquisition menu, after which the waveform trace disappeared:Any attempts to restore the trace failed, until I switched the scope off and on again.The second one bug I found affects the trace offset at higher vertical sensitivity settings where the trace shifts vertically despite having a zero offset:This is with open inputs, i.e. nothing connected. It doesn't matter if the termination is set to 1M, 50ohms or GND (actually, GND doesn't seem to do anything, but I haven't looked closer at it).Reloading the firmware didn't help (I even tried the 2x reflash as in the manual, despite having upgraded from v2 beta), and a self-calibration didn't help, either. This is most certainly a bug in the firmware, but I don't have the scope long enough to know if this a new one or an old one that hasn't been fixed/has re-appeared.Remember that I only played with the scope and the new firmware for less than an hour (and didn't even connect a signal) and immediately found two bugs, and I'm pretty sure that whenever the scope is used in anger that more bugs will surface. Not great for a product which is on the market for pretty much one and a half year.So I guess the improvements are down to a slighlty better UI and more sample memory, but the scope seems to be still pretty much a bugfest

author: nctnico
author_rank: Super Contributor
timestamp: November 25, 2015, 08:43:05 pm
content: That DC shift may dissapear when you leave it on for a while (let it heat up properly). From the SDS2000 I had I recall it needed some warming up time (much more than a few minutes!) before the DC level of the trace got to 0.

author: tautech
author_rank: Super Contributor
timestamp: November 25, 2015, 09:45:28 pm
content: Quote from: Wuerstchenhund on November 25, 2015, 07:53:57 pmNumerous attempts failed to reproduce this, anybody else seen this?QuoteI see a small ofset too, ~60uV on the 1mV setting, mine looks less than yours.If the Trigger level knob is pushed (set to 50%) the offset value will be displayed.Here's a GND input coupled screenshot, other settings same as yours AFAICT.

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: November 25, 2015, 09:47:24 pm
content: Quote from: nctnico on November 25, 2015, 08:43:05 pmI doubt it's the temperature, the scope was powered on for almost 45mins before I even started using it.

author: tautech
author_rank: Super Contributor
timestamp: November 27, 2015, 06:13:49 am
content: Has anybody got any tweaks/additions needed for the V2 FW?Bugs?Siglent are watching this thread with interest.

author: jitter
author_rank: Frequent Contributor
timestamp: November 27, 2015, 06:27:20 am
content: Quote from: Wuerstchenhund on November 25, 2015, 09:47:24 pmSelfCal? I found my Rigol needed a self cal after upgrading the firmware, perhaps the same goes for this Siglent.

author: cidcorp
author_rank: Unknown
timestamp: November 27, 2015, 07:35:02 am
content: Quote from: tautech on November 27, 2015, 06:13:49 amI started to make a list, but then got side - tracked because of my Option serial Keys not working with the new firmware.Still waiting for the person who was going to resend the keys to me.I haven't really checked this list over and it was what I started to see in the first hours of using it... some/most are just opinions.YMMV - Iwasgoing to go through thewhole scope, Triggering, Digital Channels, Arb Gen, etc but never got the optionsactivated. This was just my personal notes, I was going to post something more formal - better explained/worded.But just so I feel I'm contributing in some small way while I wait for the new keys.Here's a PDF.

author: 9a4wy
author_rank: Contributor
timestamp: November 27, 2015, 08:36:02 am
content: Did you install licenses in the FW V1??I had a same problem with licenses and I had to load back FW v1, then install licenses and then go to FW v2

author: analogNewbie
author_rank: Regular Contributor
timestamp: November 27, 2015, 01:01:26 pm
content: Does it mean that the SDS2072 can get 70M with the new V2 firmware?

author: tautech
author_rank: Super Contributor
timestamp: November 27, 2015, 01:07:13 pm
content: Quote from: analogNewbie on November 27, 2015, 01:01:26 pmYep.All models in the SDS2000 range benefit from this new V2 FW.Check the Changelog file on the first page for the other improvements......now 140K wfps, 1mV range.....

author: analogNewbie
author_rank: Regular Contributor
timestamp: November 27, 2015, 01:33:08 pm
content: Quote from: tautech on November 27, 2015, 01:07:13 pmDoes this model also have a upgrade bandwidth license input menu?

author: tautech
author_rank: Super Contributor
timestamp: November 27, 2015, 01:52:57 pm
content: Quote from: analogNewbie on November 27, 2015, 01:33:08 pmNot with this V2 FW but Siglent has been adding BW upgrade options in the FW of their other products but for now they have not offered any upgrades or pricing.In the future we hope they will.

author: cidcorp
author_rank: Unknown
timestamp: November 27, 2015, 02:55:53 pm
content: Quote from: 9a4wy on November 27, 2015, 08:36:02 amNo, but the Scope ID that I provided them was the one for the beta v2 firmware, and I tried to install the keys using the released v2firmware. So yes it was my own fault for assuming the keys were only related to the serial number (which wouldn't have changed).Siglent and Batronix have been attentive and the codes were regenerated, all is fine now.

author: tautech
author_rank: Super Contributor
timestamp: November 27, 2015, 09:27:58 pm
content: Quote from: cidcorp on November 27, 2015, 02:55:53 pmI'm surprised the Beta would have affected the scope ID, but that's why they call them Beta's I suppose.Let's hope your option install goes properly this time.BTW, thanks for your V2 FW tweak ideas, look forward to more constructive ideas like these.

author: rf-loop
author_rank: Super Contributor
timestamp: November 28, 2015, 03:10:08 am
content: Quote from: tautech on November 27, 2015, 09:27:58 pmYes, there was error in beta and it add one 0 to ID.

author: tautech
author_rank: Super Contributor
timestamp: November 28, 2015, 07:35:20 pm
content: Has the jump from 28M to 70M memory depth assisted users doing Decoding work in capturing longer communication strings?

author: Performa01
author_rank: Super Contributor
timestamp: November 29, 2015, 08:35:13 pm
content: Finally got the time to give the first release of the V2 FW a try and thought I’d share some of my findings…I started with the new (and unexpected) features, in particular memory depth and vertical sensitivity.First, I want to comment on some objections that have been raised already in this thread.After FW-update, I noticed that the confirmation-beep for keystrokes was on, which I don’t want. So I walked through several menus (‘Utility’, ‘Display’ and ‘Acquisition’ in particular) to make sure that all settings were to my liking. After that, the trace was suddenly gone. Turning the corresponding vertical sensitivity knob once brought it back immediately. A very minor issue in my book.The soft buttons generally show the currently selected option. They certainly do this when there is a menu behind the button, but also when it is just a toggle. This is consistent throughout the UI and seems very convenient to me. As far as I remember that’s not uncommon and I am pretty sure it is the same on the Rigols for instance. Generally, I would like it to stay that way.Even though a small DC offset error is to be expected at high vertical sensitivities, I took a closer look on the SDS2000. A self-calibration had been performed some 20 minutes after cold start and then the scope was running for several hours. After that, I checked the DC offset on my SDS2304 (without performing another self-calibration), and with GND-coupling, no significant error was visible on any of the 4 channels.With DC-coupling, internal 50 ohms termination and open inputs, the errors at 1mV/div were as follows:Ch.1: -740µV, Ch.2: -60µV, Ch.3: -360µV, Ch.4: -80µV.After performing another self-cal, I got the values below:Ch.1: -340µV, Ch.2: -360µV, Ch.3: -560µV, Ch.4: -640µV.It appears like the self-cal cannot really tweak out the DC offset error. But with 2mV/div vertical sensitivity, only a minor DC offset error of <+300µV can be seen. Turning the sensitivity down to 1mV/div, the offset error changes sign and can get quite significant on some channels.

author: Performa01
author_rank: Super Contributor
timestamp: November 29, 2015, 08:35:56 pm
content: 70Mpts Memory Depth:Now we actually get up to 35Mpts per channel and 70Mpts interleaved, but in terms of sample rate preservation, it is ‘only’ 28Mpts and 56Mpts, respectively.With all channels on, we can have 1GSa/s up to 2ms/div, which translates to a record length of 28Mpts. At 5ms/div, the memory increases to 35Mpts, but still the sample rate drops to 500MSa/s, as we would actually need 56Mpts in order to preserve the 1GSa/s.Likewise, in interleaving mode, i.e. just channel 1 or 2 plus channel 3 or 4 turned on, we get 2GSa/s up to 2ms/div, which results in a record length of 56Mpts. At 5ms/div, the memory increases to 70Mpts, but the sample rate drops to 1GSa/sWith the digital channels enabled, things get a little more complicated. Generally, the sample rate on digital channels cannot exceed 500MSa/s.With all analog channels on, we can maintain 1GSa/s up to 1ms/div, which means 14Mpts. At the same time, digital channels have 500MSa/s and 7Mpts.At 2ms/div, analog channels drop to 500MSa/s, thus now being equal to the digital sample rate, and memory depth is still 14Mpts on analog and increases to 14Mpts for the digital channels as well.In interleaving mode, we can maintain 2GSa/s up to 1ms/div, which means 28Mpts. At the same time, digital channels have 500MSa/s and 7Mpts.At 2ms/div, analog channels drop dramatically to 500MSa/s, and memory depth is s14Mpts for both analog and digital channels.Slower timebase settings don’t affect memory depth any further, but sample rate on both analog and digital channels drops accordingly.Conclusion:When using the SDS2000 as a DSO, we actually benefit from the increased memory. As an MSO, nothing seems to have changed, so one might assume that a major portion of the additional 42Mpts memory comes from the digital part and consequently is only available when digital channels aren’t in use.Anyway, I think this is a clever move and I’m quite comfortable with it.EDIT: Corrected analog samplerate on interleaved mixed mode.

author: Performa01
author_rank: Super Contributor
timestamp: November 29, 2015, 08:40:09 pm
content: Vertical Sensitivity down to 1mV/div:One of the most amazing (and unexpected) gifts – for me, at least – is the increased vertical sensitivity. On the other hand, this scope has always shown exceptionally low noise, so making 1mV/div available appears to be logical step. Is this just a marketing gag or is it actually useful? Let’s see…Since the hardware has not changed, it is rather unlikely that the increase in vertical sensitivity has been achieved by additional gain in the frontend – it is far more likely some form of software trick.I tried hard to find a test setup that clearly reveals what’s going on and finally ended up with the following:Scope: Single channel, 50ohms, x1, 20MHz BW limit, 500ns/div, normal acquisition, 14kpts, dot mode.Gen.: 5MHz, 3mV rms.All vertical sensitivities down to 2mV/div give 25 levels per division. Consequently, 200 levels are used for full scale and the difference to 256 (for an 8-bit ADC) is left over to give some headroom for overdriving the inputs. This can be verified by acquiring a waveform that doesn’t quite fit the screen vertically and we can still get an undistorted picture by reducing the vertical sensitivity after the fact – i.e. in stop mode.For 1mV/div, I can only see ~12 levels and, even more descriptive, I don’t see any significant difference compared to 2mV/div. zoomed to 1mV/div after stopping the acquisition.Well, together with the rather weird DC-offset issue mentioned earlier, this indicates it is indeed just a software trick, but apart from that, is it of any use?Same settings as above, DC coupled rising edge trigger, noise rejection off.- at 2mV/div, I could trigger down to ~500µV rms (with tweaking the trigger level)- at 1mV/div, I could trigger down to ~250µV rms (with tweaking the trigger level)All in all, triggering seems to be a little worse than what it used to be with prior FW versions at 2mV/div, but with the new 1mV/div setting, it is certainly at least as good, probably even a bit better.Last not least the most amazing surprise: the automatic band limit has gone!That means, we can use the full bandwidth of >300MHz even at the 1mV setting!This raises the question about the noise performance of the current implementation.With 20MHz BW-limit on:- <600µVpp for memory sizes from 70 down to 14Mpts.- <520µVpp for memory sizes from 5.6Mpts down to 140kpts.- <440µVpp for memory sizes from 56 down to 14kpts.Full bandwidth (>300MHz):- <1.28mVpp for memory sizes from 70 down to 14Mpts.- <1.16mVpp for memory sizes from 5.6 down to 1.4Mpts.- <1.08mVpp for memory sizes from 560 down to 140kpts.- <1.08mVpp for memory sizes from 560 down to 140kpts.- <1.08mVpp for memory sizes from 560 down to 140kpts.- <1.00mVpp for memory sizes from 56 down to 28kpts.- <920µVpp for memory size 14kpts.The noise levels are still low for the bandwidth. All in all, apart from the DC-offset issue, the implementation of the 1mV/div sensitivity appears to be not too bad in my opinion.

author: Performa01
author_rank: Super Contributor
timestamp: November 29, 2015, 09:11:49 pm
content: Waveform Update Rate:Well, as this seems to be the darling topic of today’s DSO enthusiasts, I had to take a deeper look into that for the final V2 implementation.I have only used 7/14kpts for this test throughout; longer memory would certainly slow down the waveform update rate on slower timebases, where the additional memory comes into effect.Tests have been generally carried out in dot mode, as I don’t see any reason for using vector mode at all with this scope.The results can be found in the attached image. Results for sin(x)/x are only given for timebases faster than 50ns/div, as the reconstruction filter is not used at the slower timebase settings, hence it makes no difference whether it’s turned on in the menu.The differences between the six configurations reveal the relative complexity of the processing going on. It might be surprising at first, that Ch. 4 only and Ch. 2+ 4 are slower than the other configurations (except for digital channels on), but this is because of the 14kpts memory as opposed to just 7k in the non-interleaved mode.As a conclusion, the banner spec. 140k Wfrm/s apply only for single channel at 5ns/div; apart from that, a maximum waveform update rate of 70k would be a more realistic figure.EDIT: As mentioned before, memory depth was kept at 7/14 kpts during the entire test, so in order to prevent aliasing I could not do the test with a constant (high) input frequency. The 2nd column of the table below shows the input frequency used, and for timebases <10ns it has been chosen such that we always get one signal cycle per horizontal division.All the measurements show the average over a period of 10 seconds. This is the only way to get close to the true sustained update rate, as the update occurs in bursts with major gaps between them.EDIT2: corrected 14pts -> 14kpts

author: tautech
author_rank: Super Contributor
timestamp: November 30, 2015, 05:36:12 am
content: @Performa01The apparent visible noise floor can be made much less with selection of Slow update in the Acquire menu as shown in reply #27. Doing this helped easily display the offset in the attached screenshot.

author: rf-loop
author_rank: Super Contributor
timestamp: November 30, 2015, 06:11:19 am
content: Here wfm/s rates tested with previous Rev 2.0Beta test version(Later I'm back in working I will also do more tests with official FW 2)All wfm/s update rates are averages so that they include least several TFT update turns.

author: Performa01
author_rank: Super Contributor
timestamp: November 30, 2015, 10:02:11 am
content: Quote from: tautech on November 30, 2015, 05:36:12 amGood tip!On the other hand, turning the 20MHz bandwidth limit on, plus limiting the memory depth to 14kpts significantly reduces the noise too - and this is what I did.Maybe adding the slow update as a third measure might reduce the noise even further - will try this the next time I have to investigate offset levels...

author: rf-loop
author_rank: Super Contributor
timestamp: November 30, 2015, 01:48:14 pm
content: Quote from: Performa01 on November 30, 2015, 10:02:11 amLimiting memory depth do not reduce noise. All noise is still there. But, it looks better due to less data. It can easy test. Turn persistence on with small meory/low sample rate and wait... all noise is there. More data, more peaaks come visible.This is still valued paper for evaluating vertical noise charaacters.http://cp.literature.agilent.com/litweb/pdf/5989-3020EN.pdfWith slow update mode, we just only reduce collected data. It need also note that more wfm/s speed...more we collect data in some amount of time. Also this is well explained in Agilent paper where they talk about example where is very slow LeCroy and then fast agilent what collect thousends of times more data in same time and then trace looks more fat.filtering _random_ noise out, example for better visualization slow (nearly like DC) offset drift. My opinion is that averaging is one best method if want see offset (DC) level under noise. Also ERES can try.When look offset drift with 2 - 5mV/div it need also note auto-cal function and if it is enabled, it some times do automatically offset corrections.

author: Performa01
author_rank: Super Contributor
timestamp: November 30, 2015, 05:58:19 pm
content: Quote from: rf-loop on November 30, 2015, 01:48:14 pmNobody has claimed anything else. I thought it was clear that we were just talking about visible (perceived) noise on the screen.Quote from: rf-loop on November 30, 2015, 01:48:14 pmYes, that's the obvious way to do it. Shame I didn't think of it right from the start - reason probably is, that visible noise with 20MHz bandwidth limit and small memory was already low enough to determine the DC-offset with reasonable accuracy.Quote from: rf-loop on November 30, 2015, 01:48:14 pmOk, I've never tried auto-cal. yet. Should definitely give it a try next weekend, even though I am a bit skeptical that auto-cal. can do some additional magic when self-cal. has failed already.As I've mentioned before, the offset error is tiny and absolutely insignificant at 2mV/div, whereas it gets quite large on some channels at 1mV/div and changes sign on top of that. Almost looks like the firmware just multiplies the RAW ADC values by 2 without taking the offset correction value into account (that is clearly in effect at 2mV/div, as there is barely any offset error visible).

author: rf-loop
author_rank: Super Contributor
timestamp: December 01, 2015, 04:09:46 am
content: Quote from: Performa01 on November 30, 2015, 05:58:19 pmYes, and sorry, only add for many other readers (not for you) due to fact that things around DSO signal "noise(s)" have so much commonly misunderstooded.Quote from: Performa01 on November 30, 2015, 05:58:19 pmSiglent autocal is perhaps not yet fully mature and not well finished. (I have not tested official V2 FW)I have not tested added 1mV/div at all.Also I do not know if HW solution for 1mV/div is exatly same in SDS2000X and SDS2000.In analog front end + ADC there is perhaps some differencies.Perhaps your suspect about offset correction "bug" is right.IF SDS2000 new FW is just modification from SDS2000X FW for SDS2000 different HW, then many things are possible.

author: Performa01
author_rank: Super Contributor
timestamp: December 01, 2015, 06:03:00 pm
content: Quote from: rf-loop on December 01, 2015, 04:09:46 amOh - seems like I've missed something there. Did not know about a new SDS2000X.So is this a new HW-revision?Does it actually exist somewhere (obviously not in Europe yet)?Does it mean I already have some outdated piece of gear by now?

author: tautech
author_rank: Super Contributor
timestamp: December 01, 2015, 06:14:05 pm
content: Yes the 2000X does exist, one was shown to Dave yesterday and they appeared on the Siglent websites on Nov 30.

author: timofonic
author_rank: Frequent Contributor
timestamp: December 01, 2015, 07:41:54 pm
content: Quote from: tautech on December 01, 2015, 06:14:05 pmWhat are the differences?

author: tautech
author_rank: Super Contributor
timestamp: December 02, 2015, 04:23:04 am
content: Quote from: timofonic on December 01, 2015, 07:41:54 pmSee first page in this thread:https://www.eevblog.com/forum/testgear/siglent's-new-product-sds2000x-series/And link to recently released data sheet ~p3 or 4.

author: cidcorp
author_rank: Unknown
timestamp: December 02, 2015, 08:01:36 am
content: Quote from: Performa01 on December 01, 2015, 06:03:00 pmAlong those lines, I'm still curious if this SDS2000X will bereplacingthe SDS2000 models, or is this tobe similar to the Rigol DS1000Z vs DS2000 (co-existing, but different). From what I see there aren't enoughdifferences in the new 'X' model for them to co-exist.As long as any improvements/fixes on the new SDS2000X firmware (over time) get trickled down to my SDS2000, I'm happy.Chris

author: tautech
author_rank: Super Contributor
timestamp: December 02, 2015, 09:49:28 am
content: Quote from: cidcorp on December 02, 2015, 08:01:36 amDistributors have know this HW revision of the SDS2000 series has been planned for some time, although there have been a few pleasant surprises by it being released as another X series product along with the move to a 16 channel MSO and the new V2 FW that has I believe taken a year in development and unleased further enhancement of the existing HW well beyond the advertised specs of when these DPO's were first released. That the new V2 FW and UI can also be shared with the existing 2000 series will be of great benefit to current SDS2000 owners as it seems more stable and vastly more bug free.The price we've had to pay has been slow V1 FW development but hopefully that should be behind us with 3 series of DSO's now using similar FW.So yes cidcorp I'd be surprised too if both series coexist, although we'd expect developments and bug fixes to benefit all models that share V2 FW or variants of it.

author: 9a4wy
author_rank: Contributor
timestamp: December 04, 2015, 08:46:27 am
content: I can find weird things on the screen in ROLL mode and measure function switched on...

author: tautech
author_rank: Super Contributor
timestamp: December 04, 2015, 08:53:19 am
content: Quote from: 9a4wy on December 04, 2015, 08:46:27 amPlease don't be scared to share them with as much detail as you can manage.

author: 9a4wy
author_rank: Contributor
timestamp: December 04, 2015, 09:32:55 am
content: first picture....ROLL MODEsecond picture...ROLL MODE with measure function switched onsometimes ROLL mode stops after "one screen aquisition"new findings.....THIS HAPPENS ONLY ON CH3 AND CH4

author: Performa01
author_rank: Super Contributor
timestamp: December 05, 2015, 08:59:45 am
content: Offset Problem at 1mV/Div:Here is a more detailed demonstration of the problem.The scope was running for >12 hours and a self-cal has been performed about 2 hours after power on. Quick-cal is also turned on, but that apparently only kicks in on major vertical gain changes and doesn’t affect offset at all.Setting for all channels: DC-coupling, bandwidth limit 20MHz, Probe x1, internal 50 Ohm termination.Screenshots including cursor measurements to show the offset distribution are provided for the situations listed below.Offset_2mV_2:Run mode, all channels set to 2mV/div, then stopped and adjusted the cursors in Y2-Y1 mode. Difference in offset voltage between all channels is 480µV, which I consider quite acceptable.Offset_2mV_zoom:In stop mode the vertical gain was changed to 1mV/div for all channels, i.e. a vertical zoom after the acquisition. The result is exactly what is to be expected, the visual offset doubles, but the difference remains the same in terms of absolute voltage, i.e. 480µV.Offset_1mV:Run mode, all channels set to 1mV/div, then stopped and adjusted the cursors in Y2-Y1 mode. Difference in offset voltage between all channels is now 1mV, which is double the amount we have seen before. This is clearly a bug, as the absolute offset cannot change regardless of the vertical gain. The expected behaviour would have been exactly the same as with the vertical zoom in the 2nd step of this test sequence.

author: Performa01
author_rank: Super Contributor
timestamp: December 05, 2015, 11:28:21 am
content: Frequency Response:Even though not normally a firmware topic, since to the best of my knowledge nothing has been published about this before, I thought I’d share some test results for the frequency response of the SDS 2304.I’ve tested all vertical gain settings in the range 1mV/div to 500mV/div at a peak to peak level of roughly 80% of the screen height. The signal generator was connected directly to the scope input via 1m of RG58 coaxial cable and internal 50 ohms termination was used, which, by the way, gives far superior results compared with a traditional external 500MHz pass through terminator.The attached images show the test results.Frequency_Response:Amplitude accuracy is generally quite good at <1% error at 10MHz, except for the new 1mV range which is a little on the high side.-3dB bandwidth is well within spec. ranging from 320MHz at 100mV/div up to 353MHz at 500mV/div.Of course these test results are just exemplary to give an idea what can be expected. In practice, all four channels behave slightly different and even bigger differences between individual scopes can be expected.F_Response_Limit:The internal bandwidth limiter was just exemplary tested for 50mV/div as there are no significant differences to expect between various gain settings. The measured bandwidth was 20.9MHz and the attenuation increases quite nicely up to at least 300MHz (not tested beyond that, as the signal was pretty much a straight line already).As a conclusion, I could not find any flaws regarding bandwidth, except maybe the lack of ETS (equivalent time sampling). Even so, this scope is clearly capable to handle frequencies up to the specified bandwidth even when all four channels are in use (hence the sample rate is limited to 1GSa/s). This wasn’t quite true for the initial V1 firmware and so this is indeed a firmware related improvement and should therefore fit the topic of this thread.

author: Performa01
author_rank: Super Contributor
timestamp: December 05, 2015, 10:49:22 pm
content: Peak Detect:/Roll ModeOne of the announced improvements for the V2 FW is peak detect acquisition mode now working. Well, to be honest, I thought it already worked (kind of) with V1, but then again, I did not test it thoroughly back then, particularly not in roll mode, as I rarely ever need timebases that slow. But today I decided to take a closer look.This is by the way one occasion, where vector display mode is useful (other than what I’ve stated before) to aid visibility. This generally applies for situations, where we’d also need to turn up the brightness of an analog scope full throttle in order to see anything (if at all) on the screenAttached screenshots document my findings.PeakDetect_10ns:This is what the test pulse looks like. It is a positive 4.72V high and 4.1ns wide pulse with a repetition rate of about 65ms. Rise- and fall times are both 2.2ns.PeakDetect_10ms:For this test, the scope memory depth was set to 70Mpts. Timebase setting was 10ms/div. Despite vector mode, the narrow pulses are barely visible, particularly the one on the trigger point at the center of the screen, obscured by the graticule. One really needs to look close – but they are there. Intensity level was set to 50%.Note that sample rate has dropped to just 500MSa/s and automatic time domain measurements show nonsense (as is to be expected, when we can get just one single sample for each pulse). Nevertheless, all pulses are reliably captured and steadily displayed, other than in normal mode, so peak detection clearly works as it should here.PeakDetect_100ms_Roll:Same situation as above, but now the timebase was set to 100ms/div and roll mode has kicked in automatically. The visibility of the pulses is a bit better, as there are now more on the screen and surprisingly, they are all there (remember, the repetition rate is about 65ms). Sometimes one pulse could get missing in the screenshot though, but that happens just when the ‘Print’ button is hit. In general, changing any settings during acquisition may cause missing pulses, which shouldn’t be a problem for most of us, who – other than Dave – don’t permanently change settings while observing a signal on any instrument.Somehow we get ghost images now, which were to be expected on a noisy signal, where we just see the extreme levels in peak detect mode. In normal acquisition mode, the signal doesn’t appear that noisy and at 10ms/div, we did get double lines too, but they were close together and far less striking.The sample rate has dramatically dropped down to 2MSa/s. There is a huge drop between 20ms/div (250MSa/s) and 50ms/s (where roll mode kicks in, 4MSa/s). At the same time, recording length drops to 2.8 Mpts, which remains constant for all timebases slower than 20ms/div when in roll mode. For instance, the slowest setting possible is 50s/div with 4kSa/s and still 2.8Mpts of memory.Automatic measurements are gone, which seems to confirm an objection recently raised in this thread.The main thing is: despite the low sample rate, we don’t lose any pulses. There is a line every 65ms and that represents the real situation quite nicely.PeakDetect_100ms:Even though roll mode automatically kicks in at 50ms/div, we can still force the scope to do a normal y-t acquisition using the “Horizontal’ menu.As can be seen, the ghosting has completely vanished on the sync signal (Ch. 2) and is far less pronounced on the main channel 4 now.So the ghosting appears to be mainly an undesirable ‘feature’ of the roll mode. But then again, with V1 FW, peak detect mode has generally been very prone to produce ghost images, so we can see a clear advantage here.Automatic measurements show even more nonsense, at least it’s consistent with the timebase setting, as the times are an order of magnitude longer compared with the 10ms/div capture.PeakDetect_1s_Roll:Just for kicks I also tried 1s/div in roll mode. Sample rate is a meagre 200kSa/s now and ghosting is bad as always, but all the pulses are still there.Conclusion:Peak detect mode works quite nicely in general. The observed flaws are either inevitable (the nonsense results from the automatic time measurements at slow timebases) or something, one should be able to live with (the ghosting issue - which isn't actually a flaw after all).The problem with automatic measurements disappearing in roll mode is not related to peak detect and is considered a serious bug though.EDIT: For all timebase settings that result in sample rates < 1GSa/s, the reason why we can still see pulses is because of the glitch capture feature – peak detect alone would not help in these situations.Also the double lines (‘ghost images’) are caused by the combined effect of glitch capture together with peak detect and get worse with decreasing effective sample rate. As the sample rate drops dramatically in roll mode, this explains why this effect is so striking there.

author: Performa01
author_rank: Super Contributor
timestamp: December 06, 2015, 04:57:33 am
content: Intensity Grading:With V1 FW, intensity grading did not work too well in many situations. This has been improved radically with V2.The scope was fed with two signals:Ch.4 is a 500mVrms / 10MHz sinewave, 100% amplitude modulated with 1kHz sine.Ch.2 is the sync signal that correlates with the zero-crossings of the modulation signal.An amplitude modulated signal can be displayed in two ways and the attached screenshots show the test results for both.IntensityGrade_LF:The scope is triggered from the modulation signal (1kHz) – in this particular test setup it is the sync signal fed into Ch. 2.Waveform update rate is only 4.5 per second in this scenario, due to the relatively slow timebase and complex signal. At least by now we should get suspicious about claims that a high waveform update rate is required to get a nice intensity graded display…IntensityGrade_HF:The scope is triggered from the carrier (10MHz) and the sync signal appears out of syncWaveform update rate is now 32k per second and the displayed result depends on the trigger settings. Here the trigger level is 78mV and has been manually tweaked to give a nice looking picture.IntensityGrade_HF_Auto:Same scenario as above, but with auto trigger level (by pushing the trigger level knob). This results in a trigger level of 4mV and the picture looks less smooth. Thanks to a working intensity grading we can make a guess though, that we’re capturing certain amplitude levels more frequently than others.Maybe this is a good place to (once again) praise the trigger system of this scope. How many scopes have we seen so far, that are capable of providing a rock-stable triggering on a 100% amplitude modulated signal at pretty much any trigger level we desire, and even auto trigger level works a treat?IntensityGrade_HF_Color:Same as above, but this time with color graded display. As someone who has used analog scopes for decades, I cannot appreciate this approach and intensity grading has much more appeal to me.Conclusion:Other than with V1 FW, Intensity grading works great on this scope now and gives me all the information I could ask for. As a side note, the rock-stable trigger system was both a great help and a joy to use for this test.

author: tautech
author_rank: Super Contributor
timestamp: December 06, 2015, 05:27:31 am
content: @Performa01Thanks very much for taking the time and trouble to go through the V2 FW in this way.It reads much better coming from you.You could make it even better to read if you did an "Insert Image" and pasted the uploaded image's URL's between each block of text. You will have to copy the image URL first and use the "Modify" but it will look tops if you want to go to the trouble.To see the syntax used "Quote" somebody elses post that has embedded images.

author: Performa01
author_rank: Super Contributor
timestamp: December 06, 2015, 05:55:32 am
content: Acquisition modes:Even though at a first glance, only ‘HiRes’ has been replaced by ‘eRes’, almost everything has changed in this area, compared with earlier firmware versions, except normal mode maybe.Since peak detect mode has been reviewed already, I thought I’d concentrate on the average and eRes modes. But then I found so many flaws in this area that I thought the entire menu deserved a dedicated post – dedicated on its general bugs alone, that is.Bug #1: Trace disappearsThis already has been mentioned before and is clearly to do with the 'Acquire' menu, particularly with the acquisition mode. Sometimes, when altering the acquisition mode, the trace disappears. Again, sometimes it can be brought back by just turning the corresponding vertical gain knob one notch – but most of the time this doesn’t help either. Then it is necessary to alter the acquisition mode again, to bring the trace and the acquisition system back to live.Bug #2: Residual trace garbage on the screenWhen switching from normal to average acquisition mode, some trace residues suddenly appeared. See attached screenshot ‘ResidualTrace_01’, where the residue can be seen in blue color.When switching back to normal mode, the residues would go away, but reappear as soon as I select average mode again.The probable cause was Ch. 2 that I had used before and switched off in the meantime. Turning Ch.2 on revealed that there was still an old acquisition stored, even though the scope has done a lot of acquisitions witch Ch. 2 turned off since then. See attachment ‘Residual_Trace_02’.Turning Ch.2 on and off several times finally deleted the trace residues from the screen.Note that the trace residue was in blue, later on also in grey, whereas Ch.2 is originally pink.EDIT: Even later on, (other) residues from Ch. 2 would appear whenever I open the ‘Averages’ menu in average mode or the ’Enhance by bits’ menu in eRes mode. It’s now mostly single dots and the color is yellow for a change. What’s even weirder, trace residues have become part of the selection menu itself (in some dark color) – and these consequently disappear together with the menu. Again, turning Ch. 2 on and off deletes the residues on the screen, but not in the menu, where they seem to be permanently burned in. See attached image 'Menu_Residual', where a dark line crosses the 1.0 setting for the resolution enhancement.Bug #3: Clear Screen doesn’t workWhile battling with the trace residues I thought “hey, didn’t I see a ‘Clear Display’ button in the ‘Display’ menu? Let’s try that!”Well, what can I say – this button does absolutely nothing. Tried the online help and it stated that this button was to clear the waveform on the screen. But it did nothing. In stop mode, it did neither clear the current trace nor the trace residues.EDIT: See attachment 'Clear_Display'

author: Performa01
author_rank: Super Contributor
timestamp: December 06, 2015, 03:42:30 pm
content: Average & Eres Acquisition Modes:These are the mystery modes, as they both do something, and they are different, but especially eRes (Eres in the menu, but somehow I cannot get used to this form) does not meet my expectations at all.Common oddities for both average and eRes acquisition modes:Memory depth is limited to 7/14k when either Average or eRes is selected and the original setting is not restored when acquisition mode is switched back to normal or peak detect. At the same time, Fast acquisition mode becomes ineffective, i.e. we can still toggle between ‘Slow’ and ‘Fast’, but the waveform update rate is limited to <10 either way, and the timebase setting doesn’t have any noticeable effect as well.The big question here is: WHY?I’ll discuss this later, as I want to summarize my findings first.Average mode does not reduce the bandwidth, but significantly slows down the response time for displaying signal variations, as can be demonstrated by the first two screenshots.First (Normal_BW_50ns_2) shows the test signals in normal acquisition mode.Ch. 2 is fed with a steady squarewave, 2Vpp, 10MHz.Ch. 4 is a 500mVrms / 10MHz sinewave, 100% amplitude modulated with 1kHz sine.The display is in dot mode.Second (Avg_BW_50ns_2) shows the same signals in averaging mode, with the number of averages of just 4.What strikes immediately is the strong noise reduction effect, which becomes even more evident in dot mode, as shown here.Other than that, the squarewave isn’t affected at all, whereas the sinewave on Ch. 4 has just a random amplitude somewhere between zero and two times the unmodulated magnitude, depending on the time of the screen capture. In other words, the display can’t follow the modulation anymore. Instead we get random amplitudes within the modulation range at a screen update rate of about 8.9 per second (but visual changes appear much slower).Even though this test was done at only 10MHz, just believe me when I say that the bandwidth is not affected by the averaging. A steady state 300MHz sinewave has the same amplitude on the screen, no matter if we use normal, peak-detect or average acquisition mode.The third attachment (Eres_BW_50ns_2) shows a very similar picture for eRes. The main difference is that the displayed variation of the modulated signal is considerably faster, even though a high resolution enhancement of 2.5bits was set and the screen update rate was still only 8.9 per second.In contrast to average mode, eRes does affect bandwidth, and as expected, the effect depends on the number of bits set for the resolution enhancement and sample rate. The maximum number of bits of resolution enhancement available depends on the timebase setting, according to the following list:Timebase Max. number of bits for resolution enhancement<5ns 1.0<20ns 1.5<50ns 2.0<500ns 2.5>200ns 3.0For 2GSa/s, the bandwidth is affected by the resolution enhancement in the following way:eRes bits Frequency Attenuation0.5 300 MHz -1 dB1.0 212 MHz -3 dB1.0 115 MHz -1 dB1.5 105 MHz -3 dB1.5 45 MHz -1 dB2.0 52 MHz -3 dB2.0 28 MHz -1 dB2.5 26 MHz -3 dB2.5 15 MHz -1 dB3.0 13.5 MHz -3 dB3.0 8 MHz -1 dBCAUTION: The table shown above is only valid for a sample rate of 2GSa/s!Because the memory is limited to just 7/14k, sample rate drops very quickly for slower timebase settings. 2Gsa/s can only be achieved in interleaved mode for timebases of 500ns/div and faster.There is a linear relationship between sample rate and eRes bandwidth. Based on the table above, half the sample rate (1GSa/s) would mean half the bandwidth, i.e. just 4MHz for -1dB error at 3 bits of resolution enhancement. In the same scenario it would be only 800kHz for a sample rate of 200MSa/s.Resolution enhancement.Both Average and eRes use some form of averaging, so a resolution enhancement could be expected for both modes. To verify this, I’ve applied just a triangle wave, see attachment ‘Resolution_TestSig’.It is a 100kHz ramp with a peak to peak amplitude slightly higher than the screen. I then switched to the AMUT (Acquisition Mode under Test), hit the Stop button and zoomed in vertically ten times (by turning the vertical gain down to 10mV/div). In dot mode (as most of the time) I thought I could just count the dots per division in order to determine the resolution.As we already know, in normal mode we have 25 dots/division, so when zoomed in 10 times we expect so see 5 dots per 2 divisions, see attachment ‘Norm_Zoom_x10’.Yes – that’s exactly what we see. So we know there are 200 points per screen height in normal (and peak detect) acquisition modes.Now let’s take a look at attachment ‘Avg_Zoom_x10’.Please ignore the blue residual trace that I’ve already covered in a previous post.Sadly, nothing has changed at all. Despite 64 averages have been set, which could give a theoretical resolution enhancement of 6 bits *), we see absolutely nothing. Oh well, quite obviously, the average mode is just meant for noise reduction and the extra resolution is deliberately thrown away.But now we take a look at the eRes mode, which carries the words ‘enhanced’ and ‘resolution’ in it’s name already – we sure would see the promised increased resolution of 2.5 bits, that I’ve set for this test, wouldn't we? Unfortunately, attachment ‘Eres_Zoom_x10’ only shows some residual trace, but not the slightest improvement in terms of resolution at all.Discussion.There are a number of oddities with these two modes and they don’t quite meet the expectations.I understand that average mode just takes an average of the specified number of subsequent acquisitions. I don’t know what the idea behind eRes is, but it appears obvious to me that it is some form of averaging within a single acquisition, which in turn acts as a lowpass filter. If I were to implement such an acquisition mode, I would make it a moving average over up to at least 64 subsequent samples (for 3 bits of resolution enhancement).Question #1: Why is memory limited to just 7/14kpts?In Average mode, if it’s a segment-wise averaging, we just need an accumulator for each sample and since the maximum number of averages is 1024 (who the hell will ever use that many?), we need 18 bits per sample. In practice this would be 24 or even 32 bits. Okay, this would eat up 3 to 4 times the original sample memory, consequently the size would decrease to 1/5 at worst, but this is still several Mpts.If average mode uses a moving average of several acquisitions – well, for an averaging of 1024 this would divide our memory by that number, but we’d still get 14k/28k and the maximum record length should increase accordingly when we select a lower number of averages.In eRes mode, we are working within the normal acquisition buffer, so virtually no additional memory should be necessary at all.All in all, it is no fun to work with just 7/14k, as we run into aliasing problems all the time and almost lose the ability to zoom into a waveform – in short, we feel reminded of all the barely usable scopes in the past (and even today) where manufacturers held the view that users generally should make do with tiny sample memories.Question #2: Why is no hardware acceleration available?Well, there’s lots of calculations with lots of data and if the hardware isn’t designed to support these operations right from the start, it might indeed not be possible to implement that as an afterthought. And yes, I think we really can live without fast waveform update rates in these special cases where we need extremely low noise and or high resolution. It’s just the combination of no hardware support and no memory, that leaves the uneasy feeling of a firmware leftover from some ancient entry-level scope that has had neither the one nor the other in the first place.Question #3: Why does eRes not enhance the resolution?As stated before, average mode could show a resolution enhancement already, but ok, since it doesn’t promise anything like that, we have to accept when it is just a means for noise reduction.eRes, on the other hand, carries the promise in its name already and the corresponding parameter is the Resolution Enhancement in bits. What is the use of an acquisition mode, that takes away hardware support, hence speed, takes away all the memory, takes away bandwidth, with no benefit other than a noise reduction for non-periodic waveforms? A DSP lowpass filter with configurable roll-off for the input channels would do a better job for this, as we would immediately know the bandwidth limit instead of having to calculate it based on the sample rate and number of bits of alleged resolution enhancement.I’m sure, the extra resolution is there originally, but somehow gets lost at some point on its way to the screen.Question #4: Why does memory depth stay at 7/14k when we switch back to normal mode?If (sad enough) the memory is limited to 7/14k for the averaging and eRes modes, it would be very much appreciated if it would return to its original value when we switch back to normal or peak detect. As it is now, we have set the memory to say 28Mpts and then switch to average mode for a short period of time. When we go back, the memory size stays at 14k and we need to access the memory size menu once again to wind it up, which is rather annoying.Conclusion:As it is now, Average Mode could be useful if we want to remove noise or calm down an unstable signal. It would be much more useful, if we had a little more memory available though.As far as the eRes mode is concerned, I’m sorry to admit that in the way it is implemented right now I cannot think of too many useful application for it, other than noise reduction for non-periodic waveforms, where the sample rate dependant roll-off has to be estimated separately for each combination of ‘resolution enhancement’ and timebase setting. The latter once again due to the lack of memory.EDIT: Clarification and additional info on eRes bandwidth limiting.EDIT2: Typo correction, 800kHz instead of 500kHz for 200MSa/s and 3 bits eRes.EDIT3:*) Theoretical, two averages would increase the resolution by two as well – but only under very special conditions, for a ramp signal with well defined amplitude and frequency synchronous to the sample rate superimposed on the input signal.In practice, we have just random noise available, so in order to get a sufficient statistical probability for the averaging result actually being close to the actual intermediate value, for a resolution enhancement of factor N, we need to have N² averages for boxcar and moving average filters and it could be even more for FIR filters optimized for a particular response characteristics.We also need this many averages in order to increase the signal to noise ratio to a point, where the additional resolution can be exploited in practice.

author: nctnico
author_rank: Super Contributor
timestamp: December 06, 2015, 05:41:21 pm
content: Is there no way to increase the memory size in Eres/average mode? It seems so silly to me that the memory is limited to 7kpts/14kpts. I have never used a scope which had that limitation.

author: Performa01
author_rank: Super Contributor
timestamp: December 06, 2015, 06:54:37 pm
content: Memory Menu.As I failed to show the memory menu in my last (already long) post, and people who don’t have such a scope might be interested what the memory menu has to offer in general, here are some screenshots.Avg_Mem: memory options for average mode (all greyed out -> none)Eres_Mem: memory options for eRes mode (all greyed out -> none)Norm_Mem: memory options for normal mode (plenty)EDIT: As we can see in the first two screenshots, the residual trace has become part of the memory selection menu as well…

author: Performa01
author_rank: Super Contributor
timestamp: December 08, 2015, 09:45:41 am
content: Measurement MenuThe automatic measurements are fine in general and I love them very much. I haven’t tried them all yet, but the ones I have used did a reliable job and gave me reasonable accurate results.I very much appreciate the complete choice of input sources that include the math channel and even four reference waveforms, and also the broad range of measurement types, particularly the channel delay measurements.There is a maximum of five measurements that can be displayed at the same time and of course they can be for different channels (Auto_Measurements, Auto_Measurements_Setup_Ch2, Auto_Measurements_Setup_Ch4).On top of that, we can have all measurements specific to one channel (thus excluding the channel delay measurements, as they require a channel group) at once in an overlay window (All_Measurements_Ch4).That works for one channel only, i.e. we cannot have more than one such window at the same time, but we can switch the input source anytime and the overlay contents switches accordingly (All_Measurements_Ch2).Now let’s concentrate on the specifically selected measurements that are displayed on the bottom line right above the soft menu bar. For these we can also turn statistics on and get another overlay that displays all the statistical data (All_Meas_plus_Stat).With all these goodies turned on, the instrument really looks quite scientific, doesn’t it?What if we change our mind and want different measurements to be displayed? Well, we can uncheck the measurements no longer needed and select some others, of course. But lazy as we are, that’s not the way we are used to do it. We rather just select the new ones and expect the oldest selections to get unchecked automatically. This works – most of the time.Suddenly I got into a state, where the selections in the ‘Type’ menu and the actually active measurements did not match any more. There are measurements selected that aren’t actually displayed and I would have to uncheck them to make them active – and vice versa. Attached there are three examples for this (Measurement_Mess_01 – 03):It seems to be a common concept with this scope to speed things up by just processing differences, but in certain situations firmware loses track of the current state. We already saw this with channel traces disappearing when cycling through the acquisition mode menu, and we have it here with the automatic measurement type selection.After I found this bug, I tried hard to find a way to reproduce it, but to no avail. I assume that it happens _sometimes_ when new measurement types are added (and we expect older ones to get deselected automatically), particularly when measurements for more than one channel are involved.

author: Performa01
author_rank: Super Contributor
timestamp: December 08, 2015, 08:10:39 pm
content: FFTFFT measurement was barely usable with V1 FW, at the very least it was very difficult to operate. The usability has been dramatically improved with V2. But is it also useful?In general, we cannot expect to get a really useful spectrum analysis with just 8 bits of resolution. Even with an ideal ADC (and everything else ideal as well), the dynamic range is limited to less than 50dB, and in a real implementation, it’s more like 45dB. While this could fit several undemanding tasks, it is one of the reasons why a scope never can replace a real spectrum analyzer, where even the cheapest entry level units offer dynamic ranges in excess of 65dB.On the other hand, a few dB of additional dynamic range can be squeezed out of even just 8 bits, when resolution enhancement techniques are applied. Let’s see what we get…For FFT, vector display mode is to be used in order to get a readable spectrum display.As window function, ‘Rectangular’ is pretty much useless, so we want to use one of the remaining three (Hanning, Hamming, Blackman). For the following examples, Hanning and Blackman have been used.Since we always want a logarithmic display for spectrum analysis, I did not bother with the ‘Vrms’ units and set up a ‘dBVrms’ display right from the start. The horizontal scale ‘Hz/div’ was set one notch down from maximum, so we get as much information as possible without wasting any screen space (at maximum, only 10 horizontal divisions are used). In this setting the total bandwidth is 10kHz, of which 7kHz are displayed on the screen.Vertical scale is set to 10dBV, which appears to be a convenient figure.Signal source is a 1kHz sinewave at 1Vrms on channel 4. Please ignore channel 2, which carries just a sync signal and is not used for FFT. It is not possible to have FFT analysis on more than one channel at the same time, btw.Just for kicks I’ve also set up an automatic measurement for the maximum level in the spectrum display (Vmax in white color). Other than that, this scope doesn’t provide any assistance for signal analysis, as any modern spectrum analyser would. So we only can display the maximum amplitude, but not the corresponding frequency and there are also no computations for distortion or signal to noise ratio and the like.As can be seen from the screenshot (FFT_1kHz_0dB_10dBV), the level measurement displays 0.00dBV, which should be right. But we see two spurious signals at 4 and 6 kHz, both just about 25dB below our signal. This doesn’t seem quite right, as the harmonic distortion of my signal generator is supposed to be better than -50dB. Let’s ignore that for the moment.Just for fun, let’s try to zoom in vertically, say 5dBV per division. Ooops … what happened to our maximum level measurement? We still see our signal at the reference level of 0dBV, whereas -200dBV would be way below the noise floor (FFT_1kHz_0dB_5dBV). BUG alarm!Appart from that, it’s quite obvious that we waste half of the screen area (I am using the split screen setting here, full screen would also be available), because the reference level is not near the top. So I move it up by 30dB and at the same time, switch back to 10dB/div (FFT_1kHz_30dB_10dBV).Okay, looks better now – but only at a first glance, because we now see two bugs at once. Vmax is now reported as -30.00dBV, which is clearly not right. The signal level cannot change at all, no matter how the display area is shifted and scaled. If anything, it could read +30dBV, as the reference level is now positioned to +30dBV and the displayed signal is exactly there. But in fact we did not actually change the reference level, but only shifted the displayed curve a little upwards on the screen.The second bug that bugs me is the displayed spurious signals that cannot be there in reality.As a comparison, I used a scope with a well implemented FFT analysis, that has proven itself in practice, and set it up very similar to the SDS 2304 scope. Just to be sure I set up twice as much bandwidth (20kHz) and doubled the number of bins accordingly, so it should be equivalent. Since I wasn’t interested in noise, I selected averaging mode – something the SDS 2304 doesn’t offer for FFT. The result convinced me, that my signal generator outputs a reasonably clean signal and the display on the SDS 2304 doesn’t show the truth. Cursor- as well as automatic measurements show that the distortion is down more than 50dB. Particularly, there are absolutely no spurs at 4 and 6kHz! Note that despite it’s just 8 bits, we manage to get about 55dB SFDR with this instrument (Pico_1kHz).So something is wrong with the FFT on the Siglent. I already was about to cancel the test and post the buggy results, as I finally discovered that I had 70M of memory selected and that the spurious signals would go away at any other memory selection. Here’s an example for 28M of memory (FFT_1kHz_28M):Even in peak detect mode, the strongest spurs (5, 6 and 7kHz) appear now >50dB below the fundamental, which means effectively nothing as this exceeds the dynamic range anyway. Well, this lets me continue the test and leaves the strong recommendation to not use 70M memory when doing FFT!The FFT on this scope has no averaging for noise reduction, so it would be interesting to see what influence the acquisition modes have on the displayed spectrum. Normal and peak detect modes give quite similar results, so I won’t show a screenshot for the latter here. But what about averaging? See screenshot (FFT_1kHz_Avg4):Memory is limited to 14k now and I have setup the test with this limitation in mind right from the start, so as not to run into aliasing troubles. I selected average mode with 4 as number of averages, so that a theoretical resolution enhancement of 2 bits could be achieved. Apart from two stronger spurs at 4 and 5kHz, that are 50dB down, nothing much has changed.With eRes, it is something different. The noise suppression is quite strong, so this setup can be useful in certain situations. We have to keep in mind though, that eRes has a lowpass effect and might pretend harmonic levels lower than they actually are at higher frequencies (FFT_1kHz_Eres2).As we know by now, the eRes bandwidth for 2 bits of resolution enhancement at 2GSa/s is 28MHz / -1dB and 52MHz / -3dB respectively. In this scenario, sample rate is just 200kSa/s, so we get a bandwidth of approx. 2.8kHz / -1dB and 5.2kHz / -3dB. Since our FFT-display shows 7kHz and the signal frequency is 1kHz it becomes obvious, that eRes already affects the third harmonic of the signal by more than 1dB.and the fifth harmonic by almost 3dB.Considering this, eRes is not really applicable for FFT analysis after all, as with just 7/14k of memory, resolution enhancements has to be limited to just 1 bit so that the eRes bandwidth limiting would not affect the FFT bandwidth.One of the major advantages of FFT is high frequency resolution at high speed – something that cannot be achieved with traditional (analog) approaches. Unfortunately, the SDS2000 fails to offer any of these two advantages. The display update rate is generally strikingly slow, at about 1 update per second, and at the same time my tests suggest that it does just a 1024 points FFT. As always, the actually usable frequency resolution is considerably lower, as can be seen in the following screenshot, where an 1kHz sinewave is 100% amplitude modulated with a 30Hz sine. This is about the limit, where the two sidebands can be distinguished from the carrier (FFT_1kHz_Mod30Hz):The settings for the above scenario were 5ms/div timebase, which results in a FFT bandwidth of 10kHz and then the maximum horizontal zoom for the FFT display was applied, which results in 100Hz/div. So this is 30Hz selectivity at a 10kHz bandwidth – and not 10Hz, as one might expect because it’s a 1024 point FFT.The last test concentrates on the analysis of narrow pulses. Channel 4 is fed with a 10µs pulse at rise/fall times of about 2ns at a repetition rate of 1kHz, that is a duty factor of 1%.FFT bandwidth was chosen to 50kHz for this test, where 35kHz get displayed.In normal mode, we do see the spectrum, but not very well, as the amplitudes are close toThe noise floor and strong aliasing can be seen (FFT_1kHz_10us_Normal).With average mode and 4 averages, the situation gets a little better, but only at low frequencies, as the aliasing becomes even more prominent (FFT_1kHz_10us_Avg4):In this scenario, eRes with 2 bits of resolution enhancement brings a dramatic improvement, even though some attenuation on the higher harmonics is already visible here, which in turn also significantly reduces the aliasing (FFT_1kHz_10us_Eres2).Conclusion:Apart from the bugs described above (automatic measurement of max. level showing street numbers, 80M memory cause spurs), the FFT is kinda usable now – within the limitations of an 8 bit system, that is. The frequency resolution is quite poor with just (estimated) 1024 points and the screen update rate is exceptionally slow at about 1 per second.EDIT: corrected estimation on SDS2000 FFT points to 1024.EDIT2: Some clarification and clarification on FFT resolution and aliasing mentioned for the pulse tests.EDIT3: Included the newest insights in the bandwidth limiting effect of eRes acquisition mode.

author: Performa01
author_rank: Super Contributor
timestamp: December 08, 2015, 11:20:02 pm
content: Trigger / Automatic Measurement BugThere’s another bug that shows if automatic measurements are used together with Math/FFT and acquisition modes Average or Eres:The first screenshot (FFT_Eres_AutoMeasure_Bug_01) shows the situation with eRes acquisition mode, where it might not become obvious that the automatic measurements aren’t updated and just keep showing the results that were valid when the scope was last time in normal or peak detect mode.Only hint is the trigger indicator, that says ‘Arm’ – even though the scope is actually triggered and the waveforms on the screen are indeed updated regularly. The problem becomes quite obvious though, when the channel 4 signal is removed – the scope still triggers on channel 2 as before and channel 4 becomes a flat line, but the corresponding automatic measurements keep showing the same values as before (FFT_Eres_AutoMeasure_Bug_02):

author: Siglent
author_rank: Regular Contributor
timestamp: December 10, 2015, 06:08:10 am
content: @Performa01Dear Performa01,Thank you for your patience and help us test the new firmware.What you write is very nice. It’s useful for us.If you have any question, Please contact us :support@siglent.comThank you for support Siglent,Best regards.

author: tautech
author_rank: Super Contributor
timestamp: December 11, 2015, 09:04:52 am
content: Quote from: tautech on December 09, 2015, 06:32:55 pmAn error was made in attaching the SDS2000X series FW to the SDS2000 FW update link.The wrong .ADS filename started like this: sds2kx and of course the FW would not load.New SDS2000 V2 FW link:http://www.siglentamerica.com/USA_website_2014/Firmware&Software/firmware/SDS2000-V2.0-1.02.01.28R1.rarYes I know it looks the same, but this one works.

author: Performa01
author_rank: Super Contributor
timestamp: December 11, 2015, 11:44:23 pm
content: @SiglentThank you very much for the response, you’re welcome.As long as I have faith in you trying to improve your products, I’ll gladly share my test results.I think the SDS2000 series has a great potential, as the basic DSO functionality is really nice and solid, which makes this scope very attractive already. If you manage to make all the bells and whistles work equally well, this scope will not only be very competitive but even a killer in the low budget market segment.From what I’ve seen so far, the new 2000X should be a step in the right direction too, regarding ergonomics and HW features.

author: Performa01
author_rank: Super Contributor
timestamp: December 12, 2015, 12:02:37 am
content: I’ve just upgraded to firmware SDS2000-V2.0-1.02.01.28R1 and will use that as a basis for any future reviews – until the next revision comes out, that is.The update went well without problems, but the self cal after the restart would hang at 5% forever. After another restart it worked though, so I’m willing to look at this as just a glitch.At this point I thought it would be helpful to make a list of all the bugs and flaws found so far for the previous SDS2000-V2.0-1.02.01.01.27 firmware. Here it is:BUGS:1. Traces sometimes disappear when switching from Average or Eres acquisition modes back to Normal/Peak Detect and only can be brought back by toggling modes once again..2. No offset error correction at 1mV/div vertical gain setting. (fixed with V2.0-1.02.01.28R1)3. Automatic measurements disappear in roll mode.4. Residual trace garbage on the screen and in the ‘Averages’ and ‘Enhance by bits’ menus after switching from Average/Eres to Normal/Peak Detect modes and using less channels.5. Clear Screen does not work.6. No memory available in Average acquisition mode.7. No memory available in Eres acquisition mode.8. Resolution enhancement in Eres acquisition mode doesn’t make it to the screen display.9. Memory depth selection is not restored when changing back from a restricted mode (Average, Eres) to Normal/Peak Detect.10. Sometimes a state is reached, where automatic measurements actually displayed on the screen don’t match the selection in the ‘Type’ menu.11. Automatic measurement for Vmax (and probably also Vtop and some others) gives nonsense readings for FFT trace.12. Strong spurious signals visible on FFT analysis with 70Mpts of memory.13. Trigger state ‘Arm’ and no automatic measurements update even though the scope is actually triggered, when Average/Eres acquisition modes are used and FFT analysis is active.FLAWS:1. Unexpected strong ghosting with peak detect in roll mode.2. Fast Mode has no effect on Average acquisition mode.3. Fast Mode has no effect on Eres acquisition mode.4. No resolution enhancement in Average acquisition mode.5. Low frequency resolution for FFT, apparently only 1024 points.6. Very slow update speed for FFT math.As can be seen, I’ve divided the list into two segments.Bugs should be fixed at any rate.Flaws are – well, just flaws, some improvement would be appreciated, but it is also clear that for some (or even many) of them there might not be any reasonable improvement possible with the existing hardware.I will not explicitly review any of these with every new firmware, unless there’s a corresponding hint in the release notes.Just by now, I’ve reviewed the 1mV/div issue and think it is resolved, as I’ll demonstrate in a subsequent post.

author: Performa01
author_rank: Super Contributor
timestamp: December 12, 2015, 12:03:38 am
content: 1mV Offset Error retestedWith the new FW release V2.0-1.02.01.28R1 there’s a hint in the release notes that the 1mV/div vertical gain setting has been corrected. Let’s see…The scope was running for >2 hours and then the firmware update plus a self-cal has been performed.Setting for all channels: DC-coupling, bandwidth limit 20MHz, Probe x1, internal 50 Ohm termination.Screenshots include cursor measurements to show the offset distribution.Offset_2mV_28R1:Run mode, all channels set to 2mV/div and adjusted the cursors in Y2-Y1 mode. Difference in offset voltage between all channels is 480µV, which is the same as in the first test.Offset_1mV_28R1:Run mode, all channels set to 1mV/div and adjusted the cursors in Y2-Y1 mode. Difference in offset voltage between all channels is 480µV again, which meets my expectations. This issue seems to be fixed.EDIT: Yes, the magnitude of the offset error at 1mV/div is now consistent with the 2mV/div setting, but it still changes sign as can be seen from the screenshots. WHY? This seems a bit odd.

author: Performa01
author_rank: Super Contributor
timestamp: December 12, 2015, 01:10:40 am
content: Frequency DisplayOn several occasions, it strikes me that the frequency display is not accurate, see screenshot (Frequency_Display_1MHz), where an accurate 1MHz (< +/-1ppm) signal is displayed as 9.99982MHz, that is an error of 18ppm.Yes, an error of 18ppm is still within the specified horizontal timebase accuracy of 25ppm, yet I was a little disappointed because even my old Rigol 1052E is way more accurate than that (in fact, it was spot on within the bounds of its 6 digit frequency counter). I even got it out of the “Not-used-anymore-but-still-too-precious-to-be-discarded-gear-cabinet” and powered it on, just to prove my memory didn’t fool me (Rigol_1MHz):But then again, the SDS2000 also appeared to be spot on at 1kHz (Frequency_Display_1kHz):Further investigations revealed the reason for this discrepancy: the SDS2000 does not have a modern reciprocal counter, like even the old Rigol does, but just a primitive standard counter with a gate time of 1s, which limits the resolution to essentially 3 digits at 1kHz. This way, the 18ppm error gets swamped of course. The display still shows 6 digits though, thus suggesting a much higher resolution (and accuracy).I consider this is a bit disappointing and would like to see a state of the art (reciprocal) frequency counter in an instrument like this, as well as a few cents more for a better internal crystal oscillator – or one that can be calibrated by the user, even though this probably would be a rather unique approach…

author: Performa01
author_rank: Super Contributor
timestamp: December 12, 2015, 05:53:46 pm
content: Self Cal only works reliably after a restart.Now I had it again. Started a Self Cal and the scope got stuck at 0%. Only after a restart, it worked as expected.This odd behaviour has been newly introduced with the latest FW revision V2.0-1.02.01.28R1

author: Performa01
author_rank: Super Contributor
timestamp: December 12, 2015, 07:12:57 pm
content: TriggerI’ve already mentioned that the trigger system on the SDS2000 is superb in my book, and now I want to back up this claim with some detailed test results.The basic settings for the test to follow are:Only CH. 4 active with DC Coupling, Full Bandwidth, Probe 1x, Impedance 50 Ohms.Display type dots, persistence 1s.Acquisition Normal, 28M Memory, Fast Acquisition.Trigger Type Edge, Source Ch. 4, Slope Rising, Holdoff Close, DC Coupling, Noise Reject Off.Unless stated otherwise, trigger level is auto-adjusted by pushing the trigger level knob once.Trigger Bandwidth:This used to be an important parameter on analog scopes, as it determined the absolute frequency limit for a stable waveform display. The same is to expect for DSOs, when analog trigger systems are used.Like many modern DSOs, the SDS2000 has a digital trigger system, hence no explicit trigger bandwidth anymore. As a rule of thumb, just about any signal can be triggered regardless the frequency, as long as it appears on the screen with a peak to peak amplitude (minus noise) that exceeds one vertical division. This is true for any digital trigger system and the exact minimum trigger amplitude varies a little between different scopes, we’ll find out what it is for the SDS2000 right now.Trigger sensitivity:As stated before, trigger sensitivity is independent of frequency, but trigger hysteresis obviously has some impact. So we start the test with Noise Reject On, which supposedly increases the hysteresis to some fixed (and unknown) value. So there is no adjustment for the hysteresis, but only two settings, Noise Reject On/Off. As mentioned before, we start with Noise Reject On, hence high hysteresis and use a rather low frequency of 200kHz for this test. Reason is – apart from the fact that signal frequency should not matter – that I’m still able to accurately measure the actual signal amplitude at this frequency (rather than just relying on the signal generator setting).Vertical gain setting for this test is 200mV/div. I don’t go any lower as I want to see the sensitivity of the trigger system alone, where noise of the analog frontend should have as little impact as possible.With auto trigger level and noise reject, we get reliable triggering down to 310mVpp, which is about 1.5 divisions, see screenshot ‘Trig_NR_min_auto’:Note that the automatic measurements suggests a level of 336mVpp, which clearly isn’t correct (+8.4%).There is also the ‘Amplitude’ measurement, which should be essentially the same for an undistorted sinewave as this, but it reads only 296mV (-4.5%).It seems that quantization noise takes its toll here.But then again, an 8-bit scope is not a precision instrument, all the more so with a signal peak to peak amplitude that is less than 19% of full screen (and less than 15% of full scale for the 8-bit ADC).Also note the frequency display, which reads complete nonsense (remember, tsignal frequency is exactly 200kHz). AT the same time, automatic period measurement shows the correct value of 5µs.With manual tweaking of the trigger level we can get down to just 150mVpp, equivalent to 0.75 divisions (Trig_NR_min_man).Automatic amplitude measurements are off again and period shows a ridiculous number. Instead, now suddenly the frequency display has at least a remote similarity with the real value.Now let’s repeat these tests with Noise Reject switched Off:With auto trigger level, we get reliable triggering down to 120mVpp, equivalent to 0.6 divisions (Trig_min_auto).Amplitude measurement appears correct here (other than Pk-Pk) and this is also true for the period, while the frequency display shows all kinds of street numbers, just not the true frequency of the input signal.With manual tweaking of the trigger level we can get down to just 50mVpp, equivalent to 0.25 divisions (Trig_min_man).Automatic measurements are totally off now, which indicates a major offset error. Despite the tiny amplitude, Period appears almost correct and even the frequency display is in the same ballpark at least.Since we got inaccurate measurements as a side effect of this test, I’ll just verify that they do indeed work as expected, as long as the signal amplitude is high enough. It appears that we need to have a peak-peak voltage level of more than 2 div in order to get reasonable accurate measurements. This is also true for the frequency display (Trig_display_verification):I’ll end this post to draw a conclusion on trigger sensitivity. And I still think it is just superb – clearly as good as it can get.The automatic measurements and all the more so the frequency display on the other hand let us down, if the peak to peak amplitude of the measured signal drops below two divisions.

author: Performa01
author_rank: Super Contributor
timestamp: December 12, 2015, 07:30:41 pm
content: Trigger Noise Reject.We have tested trigger sensitivity with noise reject on and off and got quite different results, but now we want to see how noise reject works in practice.For this test I’ve set up a noisy signal, that is just the familiar 200kHz sinewave at 500mVpp with a superimposed 150mVpp noise signal. Without noise rejection, we get the expected result: unstable triggering on both edges (Trig_Nois_NR_off).In the exact same situation, with noise reject turned on, we get a much nicer picture (Trig_Nois_NR_on).Despite the strong noise, all the spurious triggering is gone and we get a totally stable picture.Conclusion: Well done on that one!

author: tautech
author_rank: Super Contributor
timestamp: December 12, 2015, 09:13:15 pm
content: Quote from: Performa01 on December 12, 2015, 05:53:46 pmI can confirm this, however I've seen this ONLY once.In this case, use of the scope from coldfollowed laterby a Self Cal produced this freeze.But once the scope has been restarted and Self Cal'd, no amount of control adjustment or use and further Self Cal's could replicate the initial freeze.I'll run a few more tests to try and get it to happen again.......

author: Performa01
author_rank: Super Contributor
timestamp: December 12, 2015, 09:43:02 pm
content: Trigger Stability and Channel Skew.Another interesting aspect on a trigger system is its stability, i.e. the absence of excessive jitter, as well as that all channels are triggered synchronously so that we can make accurate time measurements between them.Let’s start with the stability of the trigger point which actually means stability of the trigger level and in case of a digital trigger – as here – also the proper interpolation of samples to determine the exact trigger point.First screenshot just shows the test signal – a very accurate and stable 10MHz signal derived from an OCXO – at the trigger point and minimum timebase of 1ns/div (Trig_Stability).Apart from a tiny offset error, the trigger point sits exactly where it should and absolutely no jitter can be seen. Granted, this cannot be proven by a screenshot, even with persistence of 1s turned on, but I can tell you the trace on the screen looked absolutely static.Next is the same signal, but with maximum trigger delay. I did a number of tests and this screenshot is just an example, with a timebase setting of 50ns/div and a 500µs delay. Generally, the trigger delays seems to be limited to 10000 times the timebase setting and honestly, I don’t know how that compares to other scopes as I’ve never ever had a situation where I would want the trigger point to sit far outside the visible screen area, hence I’ve never tried that before.This time I did it, just because I remember some issues with trigger jitter in a similar setup with the Rigol scopes, so I wanted to see how stable the trigger delay on the Siglent is.As mentioned before, I’ve tested this at various settings, of course also with 1ns/div and 10µs delay. In not a single case could I observe even the slightest trace of jitter though. The trigger system just cannot be faulted on this scope (Trig_Stability_Delay_500us).The last test has not much to do with the trigger system, but a lot with overall system architecture and attention to detail in the entire signal path. It is the skew between channels, which should be ideally nonexistent of course.I used a stable 100MHz signal (derived from an OCXO) to feed all four channels in parallel (Channel_Skew).At the fastest timebase of 1ns/div, we can see the sight differences in the frequency response of the individual channels, as the amplitudes are clearly different, but there is barely any skew visible between channels. If at all, we are talking about a few tens of picoseconds(!) here, and as you’ve already guessed, I quite obviously don’t have the means to guarantee that all four signals actually arrive at the scope inputs at the exact same picosecond. However, this is an impressive result in my book.It goes even further, as this scope offers a means to correct any residual skew between channels. In the example shown before, it appears like all cannels are nicely aligned, except for channel 2, that is just a tad late.A correction of 20ps for channel 2 solved this ‘issue’ (Channel_Deskew).Conclusion:The SDS2000 scope is a stable system indeed. Neither trigger level nor trigger delay time showed any noticeable jitter at all, and all four channels are nicely in sync and the ‘Deskew’ option will not see much use in practice, unless we introduce some error by mismatched cable lengths at the inputs. Once again, well done, Siglent!

author: Performa01
author_rank: Super Contributor
timestamp: December 12, 2015, 09:59:33 pm
content: Quote from: tautech on December 12, 2015, 09:13:15 pmI had my scope running continuously for at least 24 hours and done at least two self cals within the first few hours after initial startup.Then when I stumbled across the rather high inaccuracies of the automatic measurements, I estimated that even for an 8-bit system under the given circumstances, an error of 8% was a bit high, so I decided to run another self cal. Then it happened and I knew that the very same problem, that I’ve already had immediately after the FW-update, was not just a glitchEDIT: Btw, this additional self cal did not reduce the measurement errors, so we just cannot trust them for signal amplitudes lower than two divisions.

author: tautech
author_rank: Super Contributor
timestamp: December 12, 2015, 10:44:01 pm
content: Quote from: Performa01 on December 12, 2015, 09:43:02 pmAFAIK this feature is primarily used for nulling propagation delays between Current and Voltage probes especially when using the Power Analysis option to maintain accuracy of the various computed results in that mode.Siglent produce a USB powered "Power analysis deskew fixture" especially for this purpose:http://www.siglentamerica.com/prodcut-fjxx.aspx?fjid=1311&id=25&tid=1&T=2The "small current loop" part of the PCB needed to be narrowed slightly to permit my Tek P6021 current probe to be attached and perform a Deskew operation.

author: Performa01
author_rank: Super Contributor
timestamp: December 12, 2015, 11:11:30 pm
content: AC Trigger coupling.Most of the time we use DC coupling for the trigger, and there is not much to tell about it, other than it works just as it should. We rather want to examine AC trigger coupling now.Why and when would we need AC coupling for the trigger at all? Usually, we make that choice for the channel input and if we select AC coupling there, the trigger will inevitably be AC coupled as well. So there we already have the answer – we have the opportunity to force trigger into AC coupling, even when the corresponding input channel is DC coupled. This can be useful for AC signals that have a considerable DC offset and we want to see this offset on the screen. We have to use DC input coupling then and adjust the trigger level accordingly, so to get a static display of the AC portion of the signal. This certainly works without problems and we can even push the trigger level knob in order to auto adjust the trigger level (Trig_Offset_Auto).We can even move the curve around by means of the position knob and the trigger level will follow nicely (Trig Level_Follow).But that doesn’t work if the signal offset is not stable, but changes with time. The following test shows a 1Vpp 200kHz sinewave that is superimposed on a 2Vpp triangle at 100mHz, which acts as a variable DC offset here. With DC trigger coupling, we can set the trigger level wherever we want, we still cannot get a continuously triggered (hence stable in the time domain) signal. We will get just garbage on the screen periodically (Trig_Variable_Offset_DC).It’s totally different if we alter the trigger coupling to AC. Even though the trigger level is at zero and therefore appears outside the signal amplitude range, we still get a nice waveform display. The waveform constantly changes its vertical position on the screen, but remains stable on the time axis (Trig_Variable_Offset_AC).So this all works very nice, but now we finally have got some minor bug in the trigger system too. If we have a signal with a substantial DC offset and then push the trigger level knob, the scope does an auto adjust just as it would with DC coupling. The result can be seen in the next screenshot (Trig_Bug_AC_Auto):Even though it looks like the trigger level is well within the signal amplitude range, it is actually not. With AC coupling, the trigger system always ‘sees’ the centre of the waveform amplitude as zero volt, but in this example the level is set to 416mV, which is clearly outside the 440mvpp == 220mVp amplitude of the signal (according to the automatic measurement).So this is clearly a bug and pushing the trigger level knob in AC coupled trigger mode should just bring the level back to zero.Conclusion:Other than the minor bug regarding trigger level auto set, AC trigger coupling works as expected. I’ve also checked that there are no additional stability/jitter issues, so it is indeed well implemented.EDIT: Fixed some typos

author: Performa01
author_rank: Super Contributor
timestamp: December 12, 2015, 11:20:26 pm
content: Quote from: tautech on December 12, 2015, 10:44:01 pmOh yes, that certyinly makes sense - didn't think of this - but then again, in a (very) remote sense it could be viewed as some form of mismatched input cabling that I've mentioned

author: Performa01
author_rank: Super Contributor
timestamp: December 13, 2015, 08:44:03 am
content: Trigger Coupling LF/HF-Reject.Since the invention of triggered oscilloscopes some 70 years ago, filters have been used to aid in getting stable triggering on difficult signals.The SDS2000 provides lowpass (HF-Reject) as well as highpass (LF-Reject) filters, and of course even plain AC trigger coupling also is just some form of LF-Reject – a highpass filter with a very low corner frequency. I will take a look at all three here.AC Trigger CouplingI was interested in the corner frequency of AC trigger coupling and found this to be about 8Hz (Trig_Pole_AC_2).We can see that at first glance the trigger point does not match our expectation. Since the trigger is set to rising edge, we would expect it to be exactly at the zero-crossing of the rising edge, while it actually sits half way between that and the negative peak.This is because the signal frequency is 8Hz, thus exactly at the -3dB corner frequency of the AC trigger coupling circuit. This in turn causes a 45 degree phase shift, which is what we see here.LF/HF-RejectWe cannot determine corner frequencies for LF/HF-Reject in the way we did for AC trigger coupling, as these are quite obviously no analog-like first order filters, but digital with a fairly flat phase response. So I rather check the frequency where stable triggering on a signal with just one division peak-peak amplitude remains possible.For LF-Reject, the lowest possible trigger frequency is 1MHz.For HF-Reject, the highest possible trigger frequency is 700kHz.To demonstrate the usefulness of these filters, I’ve set up a signal mix consisting of two sinewaves at 500kHz and 2MHz.With AC/DC trigger coupling, as expected we can’t get a stable picture on the screen (Trig_500kHz_2MHz_AC).When we use LF-Reject, triggering consistently occurs for the 2MHz portion of the signal and even though we get multiple traces due to the superimposed 500kHz signal, triggering always happens pretty much at the same point of the 2MHz waveform, so all traces are nicely aligned with respect to the time axis (Trig_500kHz_2MHz_AC_LF-Reject).With HF-Reject, triggering consistently occurs for the 500kHz portion of the signal and despite the multiple positive going edges at the trigger level, we get a steady picture with absolutely no horizontal jitter (Trig_500kHz_2MHz_AC_HF-Reject).I obviously chose the two signal components to be close to the respective corner frequencies of the filters in the trigger path - in order to demonstrate the selectivity of the filtered triggering. In a more practical scenario, the interfering part of the signal is usually weaker and also further off the signal frequency most of the time.Of course, these filters won’t help us if we want to trigger say on an audio signal with strong mains hum superimposed, as we would need a LF-Reject filter with e.g. 200Hz corner frequency for that. It would be a very nice feature if the corner frequencies were configurable, but I honestly don’t know if there are any scopes on the market that provide such a feature, as I’ve never paid attention to this before.But there are scopes that have programmable input filters for their regular channels (even the old Rigol DS1054E has this) and with such a scope the desired frequency separation could easily be achieved by using one of the input channels with proper filter settings for triggering.Conclusion:The LF/HF-Reject trigger coupling work as expected, absolutely no complaints here.Yet there are programmable filters (LP, HP, BP, BS) for the input channels on the wishlist though, as this would be the ultimate aid in triggering/viewing difficult signals.EDIT: Fixed some typos.EDIT2: COrrection on AC trigger bandwith estimation.

author: Performa01
author_rank: Super Contributor
timestamp: December 13, 2015, 08:44:28 pm
content: Trigger Types, HoldoffAs can be seen from the number of posts related to triggering, there’s certainly a lot to be looked at – and I’ve not even touched the area of triggering on digital channels or digital signals in general (also on analog channels) yet.The time spent for reviewing the trigger system is well spent though, as it is the most important part of any oscilloscope. We just cannot seriously analyse any signal that we cannot get a stable triggering on.While I’ve concentrated on continuous signals so far, now moving over to discontinuous (gated) signals is the next logical step.For the following test I use a simple burst signal, 8 pulses 1µs wide with 1µs spacing, that is repeated every 40µs (Burst_Overview).With the usual edge triggering, we cannot get a stable trigger point, as the scope just triggers on the next best rising edge – witch might be associated with any pulse within the packet, whereas we only want to trigger on the first one (Burst_Trig_Std).This exact situation could be handled even with an analog scope, by using the trigger holdoff. The SDS2000 also has this, and as it’s a digital scope, we can set it to exact values. We just need to determine the total timespan of rising edges within the burst which is exactly 14µs and then setup the holdoff time equal or slightly longer than that. So I’ve set it to 14µs and magically triggering works as expected (this is how I got the first screenshot).Rant:Adjusting the holdoff time is a bit of a pain, as the response of the Select knob is very poor. It is too sensitive for slow movements, but also way too slow when turned faster. In short, both the initial sensitivity as well as the acceleration parameters are far from optimum. This has already been a lot better with the former V2 beta, but quite sadly returned to the painful V1 behaviour with the first official V2 release.Now what if the burst repeats every 20µs, thus leaving less than a 14µs gap between pulse packets? Does holdoff still help in that situation? Quite surprisingly it does (Burst_Trig_Holdoff).On a digital scope with a wide choice of trigger types (as the SDS2000) there are other ways to get a stable triggering on our burst signal without having to use holdoff – and as long as we have a well defined digital signal we would normally not use holdoff at all.We could use the pulse width trigger and set the trigger condition to a negative pulse width exceeding 1µs for instance (Burst_Trig_Pulse).The selection of trigger types is very nice and seems fairly complete to me (note that there is an additional menu item ‘Serial’ that only becomes visible when scrolling down the pop-up menu) and I particularly like the help screens that automatically pop up, explaining the basic functionality for any selected trigger type except Serial (where it isn’t really required anyway).The help text even considers your actual setting regarding rising or falling slope, brilliant!It is much appreciated that each trigger type has its individual settings, so that you can set up different trigger types for the same signal and then switch between them without touching the parameters over and over again. Be aware that this also includes the channel selection – so when you change trigger type and fiddle with the settings to no avail, it’s most likely that you just missed that the trigger channel is back to the initial setting (Ch. 1), which might not be the channel you are actually working with.For our little test, the Interval trigger could be used as well, if we set a range of >2µs for either the rising or falling edge (Burst_Trig_Interval).In the help text, there should be a space between ‘rising’ and the parenthesis.A very nice – and probably one of the most useful – trigger type, not usually available as a standard on many scopes (only after purchasing some ‘advanced Triggers’ bundle) is the Dropout trigger, which could also be called a timeout trigger, as it triggers at a specified time after the trigger condition has been met and state has not changed since then.In this example, we can specify this in two ways:1. State has to be low (setting: ‘Slope falling’) for more than 1µs - I've set it to 2µs (Burst_Trig_Dropout_State).2. Edge (rising or falling) not detected for longer than 2µs - set to 2.05µs (Burst_Trig_Dropout_Edge).In the help text, there should be a space between ‘rising’ and the parenthesis, but no space after ‘value’ and ‘lase’ should read ‘last’.Note that the trigger point does not correspond with any edge in the Droput Trigger types, but happens ~2µs after the trigger condition has been met, i.e. level went low.Conclusion:I haven’t tested all possible trigger types, but so far everything worked just fine and I’m very impressed with the wide choice of really useful trigger types – including even video, which I assume not many will have a need for nowadays. But then again, one can never have too many choices when it comes to triggering of some weird signal. Well done, Siglent!EDIT: That said, the resposiveness of the 'Select' knob really needs to be addressed as it is just a pain to set time parameters to a higher value in the µs or even ms range, which is really tedious and can waste a lot of time.EDIT2: Changed wording and some clarifications and additional explanations on Dropout trigger.

author: tautech
author_rank: Super Contributor
timestamp: December 15, 2015, 08:56:42 am
content: Quote from: Performa01 on December 12, 2015, 12:02:37 amHave you seen this problem with the Self Cal again?

author: Performa01
author_rank: Super Contributor
timestamp: December 15, 2015, 10:56:24 am
content: @tautechNo I haven't. But that's no surprise, as I haven't done another FW-update since then.I also haven't tried another self cal since my reply #79.Siglent apparently already has found a way to reproduce the issue - it may have something to do with automatic measurements.

author: 9a4wy
author_rank: Contributor
timestamp: December 15, 2015, 11:01:42 am
content: Quote from: tautech on December 15, 2015, 08:56:42 amMine did that once after FW upgrade(stuck at 0%) freezed...I had to restart it and then selfcal went well.K

author: Performa01
author_rank: Super Contributor
timestamp: December 15, 2015, 11:59:01 am
content: Acquisition and DisplayI thought I should take a closer look at the various combinations of acquisition and display settings.For the following tests, I have channels 3 & 4 turned on, in order to limit the sample rate to 1GSa/s and make the test results valid for the universal case where all channels are in use (with twice the sample rate, results would be significantly better of course). I will only use channel 4 though, and channel 3 just sits there idling at the centre of the screen.Test signal is a stable 300MHz 500mVrms sinewave, derived from an OCXO.Let’s start with my preferred (default) settings:Acquisition: Peak Detect, Sin(x)/x, FastDisplay: DotsThe screenshot shows a nice, clean and undistorted waveform. Even though there are only 14 samples available for the entire screen, the fast update rate of 6795Hz produces so many dots that this works almost like equivalent time sampling (Trace_Peak_Sinx_Fast_Dots).If we assume that the display update rate is about 60Hz, then with fast acquisition we get about the following:6795 waveforms per second x 14 samples per screen = 95130 samples per second. Don’t laugh. In ancient times, the ‘writing speed’ of digital scopes was actually specified that way!95130 samples per second / 60 screens updates per second = 1585.5 dots per screen. Don’t ask where that half dot is hiding – I haven’t found it yetLooking at the screenshot above, it could very well be that it contains that many dots and the result is – well, pretty similar to what we’d get with ETS (equivalent time sampling). So this might be an excuse why a scope with reasonable fast ‘writing speed’ doesn’t need ETS.With slow acquisition mode, the waveform update rate drops to 27Hz and we just get a bunch of jumping – and barely visible – dots. We still get an undistorted waveform – which is of course not visible on the screenshot, where there are actually just 14 dots (Trace_Peak_Sinx_Slow_Dots).The same calculation as before yields quite different results:27 waveforms per second x 14 samples per screen = 378 samples per second.We need not go any further – as the data is delivered at a slower rate than what the display can take, the result is pretty obvious. As long as we don’t have more than 60 waveforms per second, we cannot get more than just 14 dots per display screen update.Now let’s go back to fast acquisition and turn on vector mode instead. Screen update rate is now back to 6795Hz and the displayed waveform gets brighter and has no gaps, but it also gets a little blurred – just like an analog CRO where the brightness has been turned up (too) high (Trace_Peak_Sinx_Fast_Vectors).The blurriness doesn’t come from peak detect – it looks exactly the same in normal mode. It should be obvious that peak detect cannot make any difference in situations, where memory depth is just 14 samples and all the data make it to the screen anyway.But we do see a hint of ghosting at certain parts, particularly of the positive halfwave.Now let’s turn off the Sin(x)/x reconstruction filter (Trace_Peak_x_Fast_Vectors).Yikes – that doesn’t look pretty, does it? And dot mode doesn’t make it a whole lot better either (Trace_Peak_x_Fast_Dots).I think this is a clear demonstration, why we need a reconstruction filter whenever the digital capture of analog signals near the nyquist frequency is to be converted back into some meaningful representation of the original signal.Ok, so let’s turn Sin(x)/x back on and switch to slow acquisition, hence try our second setting again – but this time in vector mode:(Trace_Peak_Sinx_Slow_Vectors):What we can see on the screenshot is a slightly distorted sinewave. What we cannot see is the ‘jumpiness’ of that waveform. Even display persistence does not help to make this effect visible, as for some strange reason the persistence doesn’t make it to the screenshot picture.However, what happens here is that at a screen update rate of just 27Hz, the phase of the samples (thus the position of the dots) changes all the time and quite obviously the reconstruction filter isn’t perfect as it fails to produce the same results for different phasing.I’m not an expert on digital signal processing, but my guess is that a reconstruction filter cannot be error-free if not only time but also signal level is quantised. As level quantisation is low resolution (8 bits) on top of that, a sin(x)/x reconstruction just cannot give accurate results. So I don’t consider this a flaw in the firmware, it’s just in the nature of the beastIn Dots mode, this error is far less obvious, but that’s not an option anyway as signal analysis would be very difficult with just 14 jumping dots on the screenHopefully I could demonstrate why I have chosen my favourite default settings just as shown at the start of this posting.

author: Performa01
author_rank: Super Contributor
timestamp: December 15, 2015, 12:07:07 pm
content: Display PersistenceThis usually works as expected, but I’ve still found two errors.One of them has already been mentioned in my last post. The jumpy trace in the ‘Trace_Peak_Sinx_Slow_Vectors’ screenshot left a narrow shadow on the screen due to persistence mode, but the corresponding screenshot didn’t show that at all.Just to make sure screenshots normally do show the persistence, I turned some modulation on and took another screenshot (Persistence_Test):The second bug is that the ‘Display’ button toggles the persistence mode when the display menu is already displayed. So if for instance the Acquire menu is shown, I hit ‘Display’ in order to switch to the display menu, and this works as expected. But if I accidentally hit ‘Display’ again, the persistence mode changes from ‘Off’ to some random value (presumably the last one used before turning persistence off). Pushing ‘Display‘ one more time turns persistence back off again and so on.

author: 9a4wy
author_rank: Contributor
timestamp: December 15, 2015, 12:32:01 pm
content: Quote from: 9a4wy on December 04, 2015, 09:32:55 amthis problem is still here in new FW...K

author: rf-loop
author_rank: Super Contributor
timestamp: December 15, 2015, 01:08:03 pm
content: Quote from: Performa01 on December 15, 2015, 12:07:07 pmIs this useful feature really "bug"? If it need some finishing this is other case but it, as some other shortcuts are welcome. (it is possible that SDS2000X FW is not optimally personalized to SDS2000 front panel - and also different users have different learning history from many different equipments so adaptation may take some time before learn optimal way to use UI)Also it do not jump to "random" persistence time or least I have not seen any randoms. It jump to what user have previously selected(as also your presumption) . This feature jump between on/off this preset persistence. But, of course different peoples feels different depemnding how they use scope.Personally I use often persistence on and off, so it is handy, just on/off with one button, without need frequently go through menu selections.

author: Performa01
author_rank: Super Contributor
timestamp: December 15, 2015, 03:02:14 pm
content: Quote from: rf-loop on December 15, 2015, 01:08:03 pmWell, at least it is somewhat unexpected and not documented. At least not in the SDS2000 Users Manual - and I don't have any V2 FW documentation.Even though I already wondered if this might be a feature – and I'm willing to accept it as just that, it might still be debatable. I for one didn't particularly appreciate persistence mode turning on and off randomly (as it appeared to me) when I had to switch between acquisition and display menus numerous times while performing my tests.Granted, knowing about that shortcut makes all the difference, but then again it seems to be the only menu button that has such an extra functionality. So it isn’t nearly as consistent as i.e. the shortcuts provided by the knobs that include a pushbutton.

author: tautech
author_rank: Super Contributor
timestamp: December 15, 2015, 08:33:10 pm
content: Quote from: Performa01 on December 15, 2015, 03:02:14 pmIt is one of the "shortcut" features that have been added with V2 FW, first mentioned with the release of the SDS1000X series and expressed by the blue arrows next to the selection button.Of course the SDS2000 won't have these arrows but the newer SDS2000X HW does.From the SDS2000X web page:http://www.siglent.com/ENs/prodcut-detailxx.aspx?id=1243&tid=1&T=210 types of one-button shortcuts, including Auto Setup, Default, Cursors, Measure, Roll, History, Display/Persist, Clear Sweeps, Zoom and PrintThese shortcuts are enabled/disabled by toggling each specific button but just a single press enables each one's menu.IMO there should be a short description in the manuals of how to operate the "shortcut" keys along with a brief description of exactly what each key does when toggled.Siglent will be updating the SDS2000 series datasheet and manuals to include the changes brought with V2 FW. Yes, I've asked.

author: Performa01
author_rank: Super Contributor
timestamp: December 16, 2015, 02:19:19 am
content: XY DisplayOn analog scopes, X-Y mode was straightforward. Just make sure that you have the right gain settings for the respective channels, that’s it. No worries about the timebase, as this was completely inoperative and irrelevant in X-Y mode.Now I have to admit that I’ve never used X-Y mode on a digital scope before. Even with analog scopes, I used two channel Y-t mode to determine phase relationship between signals rather than X-Y mode Lissajous figures. And I’ve also long left behind the days where a scope in X-Y mode had to serve as a display unit for some homebrew gear. So I had to find out first how to do it on a digital scope when I decided to give it a try on the SDS2000…That also means that I don’t know if there are any differences between V1 and V2 FW at all.First thing to mention there is some redundancy, as we can select X-Y mode in the Horizontal menu (that was expected) and also in the Acquisition menu – I would rather have supposed to find it in the Display menu, as I don’t consider it to be a special acquisition mode.But in some sense it is, as the memory is once again limited to 14k, and this time the other memory options are not just greyed out, but not even there at all. That once again means we have to carefully adjust our signals so that the screen shows at least one full period of each signal involved and no aliasing occurs (XY_Signals_2).This step is necessary as X-Y mode can only work with the data captured in Y-t mode, that is clearly active in the background even when in X-Y mode. So this is a big difference to analog scopes, where we didn’t need to worry about timebase settings at all when in X-Y mode.Once the signals are properly set up in Y-t mode, we can actually get a nice Lissajous figure in X-Y mode (XY_Display_2):Couldn’t resist creating a new Siglent logo (XY_Display_3)Waveform update rate for the above tests was close to 4000Hz, so as a display unit, the SDS2000 would be just as responsive as any old CRO. And as I think X-Y mode is very special and will not see much use anyway, I don’t even complain about the memory limitation either.Conclusion: X-Y mode is different to analog – a trap more for old- than young-players, I guess – and I think it works just fine on the SDS2000.

author: Performa01
author_rank: Super Contributor
timestamp: December 16, 2015, 03:01:30 am
content: Another Trigger Jitter Test.I just came across a scenario which I thought might be worth sharing.Fast Acquisition, Peak Detect, Sin(x)/x, 35Mpts.Display Type Vectors.Ch. 3: 60 MHz Sine, 1.2 VppCh. 4: 1 MHz Sine, 1.2 VppEdge Triggering on CH. 4, rising edge, 20mV.The first time I've ever seen some jitter on this scope, but that is to be expected when triggering on a really slow edge like this (Trig_Sine_Vectors):We see a jitter of about 5ns, which is still very impressive!The trigger edge rises less than 17mV within 5ns, so that is also the uncertainty of the trigger level, which in turn causes the jitter observed on the Ch. 3 waveform. As the vertical gain setting is 200mV/div; that means the uncertainty is just about 8% of a division, which in turn corresponds to exactly 2 LSB of the ADC. That is about as good as it gets.Changing the signal on trigger channel 4 to a squarewave with a rise time of about 13ns, all the jitter disappears as expected (Trig_Square_Vectors):This is just another proof that the most important part of any scope – the trigger system – really is as good as it gets on the SDS2000.

author: tautech
author_rank: Super Contributor
timestamp: December 16, 2015, 03:03:04 am
content: Quote from: Performa01 on December 16, 2015, 02:19:19 amDots?I ask because the waveform looks "grainy"Quote

author: Performa01
author_rank: Super Contributor
timestamp: December 16, 2015, 04:27:24 am
content: History Display.One of the really nice features on the SDS2000 is the history display. This is a very useful analysis tool as it allows the examination of not just the current screen but also a bunch of acquisitions that have been taken in the past. The good thing is it doesn’t need to be enabled explicitly, it’s just always there and can be accessed whenever it is needed.Of course, for this feature to be useful we need deep memory, and that’s where the 35/70 Mpts now available with V2 FW really help. On the other hands, restricted acquisition modes like Average and Eres, where there is no memory available, are pretty much ruled out by that.For this test I’ve just setup two arbitrary signals on channels 3 and 4 and used peak detect mode with max. memory.Ch. 3: 50MHz, 1.2Vpp sinewave, 100% amplitude modulated at 1kHz.Ch. 4: 10MHz, 1.2Vpp squarewave.The first screenshot shows the signals in Run mode (Hist_Sig):Once we hit Stop (or access the history menu, which also stops the scope), we can either manually scroll through the individual acquisitions or automatically playback the entire history buffer in either direction at almost any interval we like. In this scenario, we got 80000 history frames and we can turn on a list display that shows the history frames including number, timestamp and time difference of the respective acquisition.In manual mode, we can just scroll through the list, which can be very time consuming if there are 80000 entries, just as in this scenario. The list as well as the screen display is updated accordingly.Just two examples for manual mode:First, I manually selected a random acquisition where the amplitude modulated signal on Ch. 3 was at a minimum (Hist_Display_Min).Second is an acquisition where the amplitude modulated signal on Ch. 3 was at a maximum (Hist_Display_Max).We can also start history playback in either direction and hit the pause button anytime, and then continue with manual mode for instance. Playback interval can be anything from 1µs up to 1s. This means the interval at which the individual history frames are displayed and of course 1µs isn’t a realistic number, as the scope just isn’t capable of displaying frames nearly as fast as 1 million per second. The fastest I could get was about 2000 frames per second, which means we can playback 80000 frames within some 40 seconds. The amplitude modulated waveform looks almost like in run mode, just the screenshot doesn’t exactly show that as the playback slows down a bit when hitting the print button (Hist_Playback).BUG Alert: While playing with the history mode, I tried to playback the history buffer at maximum speed, i.e. with an interval setting of 1µs. Of course it wasn’t nearly as fast as that, and after several thousand frames, playback suddenly stopped and then scope would respond to keystrokes only with a lag of several seconds. History mode was not operative any more. See screenshot (Hist_Frozen).After hitting the Run/Stop button, the scope came back to live after several seconds. I tried it one more time, and it happened again, even with an interval setting of 10ms. After several attempts I finally managed to get it to playback the entire history buffer at an interval of 10ms. I did not need to restart the scope to get there, but it happened again and again, so history mode certainly is not yet reliable in operation yet.Conclusion:Apart from the bug described above, I think history mode can be extremely useful in general and even though there is no means for quick navigation within the history buffer, i.e. a jump function or something similar, it is still very usable.

author: rf-loop
author_rank: Super Contributor
timestamp: December 16, 2015, 07:21:48 am
content: Quote from: Performa01 on December 16, 2015, 04:27:24 amI can repeat this with next notes.I can not repeat this if trigger source is CH1 or 2.I can repeat this error if trigger source is CH3 or CH4Independent of how many channels are acqured.I'm not sure but looks like that also independent of history playback interval time setting.Also looks like independent of if history playback display mode is dots or lines and Sin(x)/x on or off what also affect playback max speed.Also looks like this problem is independent if math, including FFT or measurements or cursors are used in history playback mode or history is horizontally zoomed or horizontally shifted.My rest life is not enough for test all possible settings combinations but strogly it looks this error is somehow connected to trigger source used in acquisition(?).(also I have tested 1,2,3 or 4 channels on separately and 1+2 or 3+4 and also used every channel for trigger source. But every time if trigger source is CH3 or 4 in acquisition then history playback suddenly stop to random position and after then history freeze until run scope agen using run/stop or other things like default or autoset. (it looks like there is least less this problem if timestamp table is off during playback)My version isFW: 1.2..1.28.1FPGA: 15.11.17-15.11.17-15.11.26HW: 3-3Model: SDS2304

author: Performa01
author_rank: Super Contributor
timestamp: December 16, 2015, 08:13:27 am
content: Quote from: tautech on December 16, 2015, 03:03:04 amYes, it certainly was dots display, as this is my default setting.I know, I could (should?) have changed it to vectors for the new Siglent Logo at leastIn general, I don't mind a little 'grain' and only switch to vectors display if it really is required to aid in visibility.

author: Performa01
author_rank: Super Contributor
timestamp: December 16, 2015, 08:31:08 am
content: Quote from: rf-loop on December 16, 2015, 07:21:48 amYes, that's what I found too. As I wrote, it also happened at 10ms interval, which is much slower than what the scope can do.Quote from: rf-loop on December 16, 2015, 07:21:48 amSo our firmware and FPGA program are identical, only the hardware differs (mine is 5-3).

author: tautech
author_rank: Super Contributor
timestamp: December 16, 2015, 08:37:14 am
content: Quote from: Performa01 on December 16, 2015, 08:31:08 amrf-loop's and mine are bothpre-release dealer unitsmodel SDS2304 HW: 3-3 and are missing the MSO port and associated componentry, but same PCB AFAIK as the 5.3 HW.

author: rf-loop
author_rank: Super Contributor
timestamp: December 16, 2015, 11:44:18 am
content: Quote from: tautech on December 16, 2015, 08:37:14 amYes. There mey be some tiny mechanical/HW "adjustments" in official marketing versions after pre-release version.Example some pre versions may have extra noise in channels. This is because aluminium is not always easy material due to surface oxide layer. If there is extra noise and unit is pre version, there may need tiny mod around internal aluminium chassis and input BNC's. Contact from inteernal aluminium chassis and BNC GND surface is not very good.I have never seen this problem in official market versions after pre "demo"version.

author: Unknown
author_rank: Unknown
timestamp: December 16, 2015, 01:40:28 pm
content: Hello, Performa01.I just thought I would let you know that the Siglent SDS2000(X) product engineering people have been reading your posts on this thread. They are currently working on the issues you have noted.Thanks for your help.

author: Marchello
author_rank: Contributor
timestamp: December 16, 2015, 02:53:10 pm
content: Quote from: Siglent America on December 16, 2015, 01:40:28 pmHello!When SDS2074X will be available for purchase?Best regards!Mark.

author: Unknown
author_rank: Unknown
timestamp: December 16, 2015, 02:59:12 pm
content: Quote from: Marchello on December 16, 2015, 02:53:10 pmHi Mark.I can't speak for the areas outside North America but they are for sale here in N.A. now. The stock quantities will be small for awhile, however.Regards

author: Performa01
author_rank: Super Contributor
timestamp: December 18, 2015, 11:28:20 pm
content: Digital Channels broken.I’ve briefly reviewed the digital channels with firmware SDS2000-V2.0-1.02.01.01.27 a couple weeks ago and found them basically working.Now I wanted to take a closer look and thought about sharing my experiences here.Quite sadly I found the digital channel function broken again with firmware SDS2000-V2.0-1.02.01.28R1, see attached screenshot (Digital_Broken):Yes, decoding basically works and all the signals appear to be there, but all channels are at the same vertical position.

author: Performa01
author_rank: Super Contributor
timestamp: December 20, 2015, 01:28:01 am
content: Wave Gen.I’ll start this review with some general thoughts.As with most additional features that go beyond the core functionality of an instrument, we cannot expect them to replace dedicated gear, rather have to accept a bunch of limitations.A DSO is just a DSO and just like the integrated trigger frequency measurement and the automatic measurements cannot replace (proper) frequency counter and multimeter, this is also true for the built-in waveform generator – but it could still be very useful when at a pinch.The built-in Wave Gen of the SDS2000 is a single channel arbitrary waveform generator without sweep and modulation capabilities.Many dual channel arbitrary waveform generators have been introduced during the last decade and these can be incredibly useful. Before that time, however, we had to make do with just one channel and this is still enough for the majority of applications today.Even the old analog function generators provide internal/external sweep capabilities, i.e. frequency modulation. Nowadays we expect a complete set of modulation capabilities together with an internal universal modulation source, which means there must be essentially another DDS-generator per channel. The SDS2000 obviously doesn’t have a spare DDS generator to be used as modulation source and it doesn’t have the connectors usually associated with a fully-fledged waveform generator, like trigger/gate in, modulation in/out, sync out, which is no surprise, considering it is just a DSO after all.However, a sweep function could have been easily implemented just in software.According to the data sheet, it is a 125 MSa/s, 14 bits system with 1µHz of frequency resolution.These specs sound good and would have been a big deal even just a decade ago. But the specs aren’t everything; what counts at the end of the day, is the actual signal quality.The frequency range covers 25MHz for sine, 10MHz for square, 300kHz for ramps and 5MHz for arbitrary waveforms.This is not too bad either. In the good old days, analog function generators were usually limited to 2MHz, and most early DDS function generators could not exceed 10MHz.The output impedance is proper 50 ohms, but the maximum signal level is limited to 3Vpp into 50 ohms (6Vpp open circuit).That’s a typical limitation of many built-in generators, as they lack a proper output amplifier that could provide 20Vpp open circuit and 10Vpp into 50 ohms. It should still be enough for a bunch of everyday tasks though.Actual frequency resolution is just 2 or 4 digitsWhen reviewing the specs, the claimed frequency resolution of 1µHz is rather misleading. While the lowest frequency is indeed 1µHz, the default frequency resolution is exceptionally low at just 2 digits. This can be changed to ‘fine’ adjustment, where the resolution is 4 digits. That means that above 10MHz, the smallest frequency step is 1kHz, which might be too coarse for some measurements, such as determining the bandwidth of a 10.7MHz IF filter for instance. On the other hand, given the poor response characteristic of the select knob, this approach is still welcome as it would otherwise take hours to go through the entire frequency range.The resolution for amplitude setting is 2 or 4 digits as well.WaveformsThe Wave Gen provides all the standard waveforms including DC and noise, plus a few built-in arbitrary waveforms and 4 memories for user defined waveforms (AWG_Gauss)I don’t know how well it works to create a user defined waveform and then transfer it into the scope memory. The manual suggests to use EasyWave, which didn’t come with the scope (there are just a couple PDFs on the CD). We should be able to download it from Siglent’s website, but since I wasn’t particularly interested in arbitrary waveforms right now I couldn’t be bothered.Btw, the datasheet claims a maximum of 16k for the arbitrary waveform length.Now let’s take a closer look at some waveforms:SineAmplitude accuracy appears quite good. At 1kHz, a 2.8Vpp signal measures 1.00864Vrms, which is not too far from the expected value of 0.99Vrms, indicating an error of +1.8%. This really is not bad at all, given the fact that the actual resistance of my pass-through terminator is a bit high at 50.259 ohms.The same experiment without pass-through terminator results in an output of 1.00596Vrms and the error is +1.6%.No matter how many bits and what the sample rate is, what really counts is the signal quality. I don’t have a proper spectrum analyser right now, but I can make accurate THD measurements up to 20kHz and will use a properly implemented FFT on another scope to look at the frequency range above.At 2.8Vpp into 50 ohms, the measured distortion levels from 20Hz to 20kHz are generally below 0.01%, thus would be well suited for quality audio measurements (AWG_THD)As already mentioned, for higher frequencies I have to use the FFT on another scope, which doesn’t provide the dynamic range to measure distortion figures below 0.1%. In order to check the limits of my test setup, I measured 10kHz once again (AWG_Spectrum_10kHz)THD is measured as 0.066% now, whereas the true figure is an order of magnitude lower. This test setup will still be useful, as the distortion figure inevitably rises at higher frequencies, hence will eventually enter the dynamic range available.The sinewave remains nice and clean up to 5MHz, where distortion is still below 0.1%, but non-harmonic spurs touch the -60dBc mark (AWG_Spectrum_5MHz)Distortion and spurs keep rising with increasing frequency and at 10MHz, THD starts exceeding 0.1% (AWG_Spectrum_10MHz)At 25MHz, the signal shows all kinds of harmonic and non-harmonic content and THD is measured as 0.355% (AWG_Spectrum_25MHz)All in all these results aren’t bad at all – at least the real thing appears a lot better in terms of spectral purity than what the rather unexciting specs in the datasheet would suggest.SquareI’ve checked the square wave across the entire frequency range and could not find any flaws. Overshoot is next to non-existent and there particularly is no ringing, provided the scope input is properly terminated at 50 ohms. Rise- and fall times are both 24ns, which is still fast enough to produce a nice looking squarewave at 1MHz (AWG_Square_1MHz_2800mVpp)At the maximum frequency of 10MHz the output doesn’t looks very square anymore, but that’s to be expected (AWG_Square_10MHz_2800mVpp)So no complaints here either. The rise- and fall times are exactly as specified, and overshoot is actually much better.PulseMinimum pulse width is 48ns, rise- and fall times are the same as with square. Again, the pulse looks nice and clean (AWG_Pulse_48ns_2800mVpp)RampRamps are limited to a maximum frequency of 300kHz but the linearity looks still pretty perfect at that frequency in exchange. I chose a symmetry of 0% and as a big surprise, the leading edge has a risetime of only 12ns. So ramp can do twice as good as square and pulse (AWG_Ramp_300kHz_2800mVpp)NoiseNoise at the maximum standard deviation of 225mV provides a reasonable flat spectrum up to 10MHz and submerges in the noise floor of my test setup (some -98dBV) at about 115MHz (AWG_Noise_225mV_2800mVpp)ConclusionThe Wave Gen option on the SDS2000 is actually quite a useful signal source. Without any bells and whistles, particularly no sweep capability and limited output level, it still does the job for many applications and performs significantly better than specified in terms of signal purity.

author: Performa01
author_rank: Super Contributor
timestamp: December 20, 2015, 08:45:40 am
content: Noise ReductionJust a few experiments with an extremely noisy signal.Ch. 4 input: 1kHz, 500mVpp sinewave with 250mVpp white noise superimposed.CH. 4 settings: DC coupling, full bandwidth, Probe 1x, Impedance 50 ohms.Rising edge trigger on Ch. 4, HF-reject, Noise Reject on.Display type dots.With the above settings, I get a rock stable triggering despite the strong noise.In normal acquisition mode, the trace (or should I rather say ‘track’ or even ‘field’?) looks like this (Noise_Norm)In peak detect mode, we get the extremes only – because display type is dots! – so we effectively could call this ‘Envelope Mode’ – another reason why dots mode is a good default setting. Noise amplitude level now appears even higher a bit higher than it was set on the generator (Noise_Peak)The same situation with display type vectors doesn’t look much different to normal acquisition mode – yet the envelope is still visible to some extent (Noise_Peak_Vectors)But now we want to see the noise reduction of average mode. With just 4 averages, the effect is quite noticeable already. The original noise level of 250mVpp has been reduced to 125mVpp. The screen capture looks like there is even less noise, but this is only because now the waveform update rate is slow at about 5/s (one of the limitations in average mode), not showing all the scattered dots at once (Noise_Avg_4)With 16 averages, the noise level halves again and is now 62.5mVpp (Noise_Avg_16)With 64 averages, the noise level halves again to 31.25mVpp (Noise_Avg_64)64 averages is about the sensible maximum; Not much can be gained with further increasing the averages. For instance, 256 averages do not halve the noise (as would be expected) – probably because we’re now in the realm of numerical noise introduced after the averaging process. Noise is now down to some 20mVpp (Noise_Avg_256)For the reasons mentioned before, I did not test the 512 and 1024 averages settings, as they need very long to settle and still don’t reduce visual noise any further.In this context, it would be interesting to see how strong the effect of the 20MHz input bandwidth limit is in this scenario. Yes, it does indeed affect the noise level, that is now down to 190mVpp (Noise_Peak_Limit)The noise source for this experiment has a bandwidth of just 60MHz, so the reduction could be expected to be much stronger if the noise bandwidth were >300MHz.

author: Performa01
author_rank: Super Contributor
timestamp: December 20, 2015, 10:21:05 pm
content: I thought it was a good time to provide a new list of all the bugs and flaws found so far for the SDS2000-V2.0-1.02.01.28R1 firmware, including all the bugs found in previous firmware versions, that have not yet been confirmed to be solved.Bugs:1. Traces sometimes disappear when switching from Average or Eres acquisition modes back to Normal/Peak Detect and only can be brought back by toggling modes once again.2. Automatic measurements disappear in roll mode.3. Residual trace garbage on the screen and in the ‘Averages’ and ‘Enhance by bits’ menus after switching from Average/Eres to Normal/Peak Detect modes and using less channels.4. Clear Screen does not work.5. No memory available in Average acquisition mode.6. No memory available in Eres acquisition mode.7. Resolution enhancement in Eres acquisition mode doesn’t make it to the screen display.8. Memory depth selection is not restored when changing back from a restricted mode (Average, Eres) to Normal/Peak Detect.9. Sometimes a state is reached, where automatic measurements actually displayed on the screen don’t match the selection in the ‘Type’ menu.10. Automatic measurement for Vmax (and probably also Vtop and some others) gives nonsense readings for FFT trace.11. Strong spurious signals visible on FFT analysis with 70Mpts of memory.12. Trigger state ‘Arm’ and no automatic measurements update even though the scope is actually triggered, when Average/Eres acquisition modes are used and FFT analysis is active.13. Self Cal hangs and scope has to be restarted.14. Automatic trigger level for AC trigger coupling behaves the same as with DC coupling, instead it should reset the trigger level to zero.15. Display persistence doesn’t show on screenshots for small signal variations.16. History mode freezes during playback (probably only when trigger channel is 3 or 4).17. Digital channel display broken.Flaws:1. Unexpected strong ghosting with peak detect in roll mode.2. Fast Mode has no effect on Average acquisition mode.3. Fast Mode has no effect on Eres acquisition mode.4. No resolution enhancement in Average acquisition mode.5. Low frequency resolution for FFT, apparently only 1024 points.6. Very slow update speed for FFT math.7. Offset error changes sign at 1mV/div vertical gain setting.8. Trigger Frequency Counter not reciprocal, thus very low resolution at frequencies <1MHz.9. Frequency counter accuracy considerably worse than competition.10. Automatic measurements very inaccurate for signals with pk-pk amplitude less than 2 divisions.Bugs should be fixed at any rate.For the flaws, some improvement would be appreciated, but it is also clear that for some (or even many) of them there might not be any reasonable improvement possible with the existing hardware.

author: nctnico
author_rank: Super Contributor
timestamp: December 20, 2015, 10:39:21 pm
content: Still not going to return it? You have not gotten to protocol decoding yet...BTW: did you try to move the digital channels? In an ancient firmware version you could move the digital channels individually.

author: TheDefpom
author_rank: Frequent Contributor
timestamp: December 22, 2015, 02:15:22 am
content: One thing I wish the firmware did is to not give a false impression of accuracy on the frequency display, it should reduce the number of digits to remove the trailing zeros, which make it look like it has a precise reading, when in fact it does not!Maybe a way of adjusting the accuracy of the display could be added to the firmware also, to allow for the reference oscillator not being exactly on frequency, a calibration point, so it can be compensated for to give correct frequency display, at the moment it is of little use to me because it is so far out of accuracy.

author: Performa01
author_rank: Super Contributor
timestamp: December 27, 2015, 01:17:00 am
content: Quote from: nctnico on December 20, 2015, 10:39:21 pmNot me!In general it’s a great DSO already, with exceptional low noise and a rock solid trigger system.Granted, there is a number of bugs yet, but none of them is a show-stopper and I’m positive they’ll be fixed eventually.Average acquisition mode suffers from the memory limitation, but then again, for the price I paid for the SDS2304, I might have got a WaveAce 2024 at best, where apart from the lower bandwidth and it’s not being an MSO, I wouldn’t have had to worry about memory limitations in certain acquisition modes, as there are generally not more than 12kpts per channel available...Eres is even worse, as it doesn’t even do what it promises, but then again, how many scopes in this class do have a useful resolution enhancement in the first place?FFT isn’t terribly useful, but this is also not uncommon in this class and quite obviously only manufacturers who offer scopes with 12 or more bits (where FFT starts to make really sense) go to the effort to implement it in a way such as to get the most out of it.Only real annoyance is the trigger frequency counter, as it is low resolution, inaccurate and unreliable all at the same time. Where are the days, when we had analogue scopes with a Y-output, where we could hook up the frequency counter that had the resolution and accuracy that we needed for our task?Quote from: nctnico on December 20, 2015, 10:39:21 pmYou are perfectly right – the bug I’ve observed is just about the initialization as it seems. Arranging the channels manually works, and even a nice auto arrangement (just as I’d have expected it right from the start and as it was in previous FW version) can be had by just one push on the position knob.Quote from: nctnico on December 20, 2015, 10:39:21 pmHopefully I will get to test the digital channels anytime soon. But what I can tell already, in principle everything seems to work – also parallel and serial decoding.

author: Performa01
author_rank: Super Contributor
timestamp: December 27, 2015, 01:20:21 am
content: Pass Fail ModeThis is an extremely valuable feature for finding anomalies in a signal – if it’s properly implemented, that is. On some scopes, the pass/fail test is dog slow and finding a glitch could take forever. So let’s see what the SDS2000 has to offer in this regard…For this test, I use a basic square wave at 1MHz, 50% duty cycle, about 2.6Vpp amplitude and 12ns transition time for both edges. The automatic measurements indicate slower transition times, most likely because the signal generator doesn’t quite meet its specs at full amplitude of 10Vpp into 50 ohms and my test setup eats up a little speed too, with a total of 2 metres coaxial cable and a homebrew power-splitter (which is also the reason why only a fraction of the original amplitude makes it to the scope input).Acquisition mode is peak detect and display type is dots (Waveform)Now it’s time to prepare the mask for the test. I set the tolerances to 0.16 divisions for both x and y direction, that corresponds to 16ns and 80mV, or +/- 8ns and +/- 40mV, to be precise (Mask)Please ignore the numbers in the Total/Pass/Fail display on the top right corner – these are just old values that will only be reset when a new test is started – which makes sense of course.Now we can run the test for the first time – and nothing happens, other than the Total and Pass numbers count up at a rate of about 38000/s, which is – what do you know – exactly the waveform update rate for this setting. The Fail count stays at zero, as is expected for stable and undisturbed waveform.Now we can make the waveform faulty – for instance by changing the square to a sine – but I didn’t want to be that uninspired. Instead I changed the rise time from 12 to 24ns on the signal generator, thus making sure the rising edge would violate the horizontal tolerance window by a few nanoseconds. I ran the test for 60 seconds, and sure enough, the result met all my expectations (Pass_Fail_SlowRise_60s)The test ran 38000 times per second, resulting in a total of 2284039 inspected waveforms – and none of them passes the test. In other words, the SDS2000 generated some 38000 errors every second, which is quite impressive.What is the real detection rate then? At 1MHz, we get one million faulty (slow) edges per second, and because of the trigger speed (waveform update rate) of 38kHz, the ‘examination rate’ is 3.8%. That means, if the fault is intermittent, statistically the test needs to run long enough for about 26 abnormal frames to occur, in order to detect the anomaly once. Not a bad prospect at all.Now for the really tough testI set up a second signal that can be superimposed on the basic waveform – it’s a nasty little positive spike, 100mV in amplitude and only 10ns wide at a repetition time of 100ms. Transition times are supposed to be a tad over 2ns and the scope says 3 – so my test setup isn’t that bad after all, considering the scope itself is supposed to have a rise time of about 1.2ns. Please note that both the vertical gain as well as the timebase settings are very different to the previous screenshot (Glitch)Both signals mixed together provide the sporadic signal anomaly that I wanted to use for this test. Because of the low frequency of just 10Hz only one in 100000 waveforms gets disturbed and the deviation from the original is rather tiny. Please ignore channel 2 which is just a sync signal that was required for triggering in order to get a nice screenshot, as the glitch is not synchronized to the base waveform, i.e. it appears randomly anywhere on the trace (Waveform_Mix)I did another 60 second pass/fail test with the signal shown before (Pass_Fail_Glitch_60s)Because of the glitch just occurring once in 100000 periods of the base signal, we would expect a pass/fail ratio of just that. In fact, the scope detected almost twice as much abnormal acquisitions, as the ratio was 2298858 / 42 = 54700. I guess that’s just the pitfalls of statistics – if the test would run for a longer time, I expect it to converge to the expected ratio of 100000.On a side note, when playing with the pass/fail test, a similar bug as already reported for the history mode can be observed. In rare instances, the scope stops showing a trace and only responds to keystrokes with a considerable delay. As with the problem in history mode, hitting Run/Stop twice brings the scope back to live. The bug happens much less frequently here than it did in history mode. According to the tests done by rf-loop, it might well be that it has something to do with the trigger channel. I consider it a good thing that I use channel 4 for the majority of my tests, as most folks – particularly firmware developers/testers– will probably just use channels 1 and 2 most of the time and expect 3 and 4 to behave the same – which isn’t always true, as we have learned by nowConclusionApart from the little bug described above, the pass/fail test works just great – in fact much better than on many other scopes we’ve seen so far in this class. Well done Siglent!

author: rf-loop
author_rank: Super Contributor
timestamp: December 27, 2015, 07:24:25 am
content: Note1:This test is old. From December 2014.At this time SDS2000 FW was some old V1 version.Note2: Mask used in Siglent made using PC.Note3: Images resized so that on the PC screen can note difference between 8" and 7" display.In these tests SDS2k maximum wfm/s average speed was barely around 110kwfm/s. (highest burst speed of course more - inside one display update period) Today with V2 FW versions average max 140kwfm/s.First Rigol DS1000Z series oscilloscope.Scope looks nice, rich of features, display looks nice and well finished and so on.First this is example how bad it can be.In this test Mask test fails continuously (every acquire fail)Speed is 1 waveform per second. Really, it can capture one waveform in one second in pass fail test in case that test result is fail.Then we can look how its speed go with Siglent.Here with Siglent. Every acquired waveform fails in test. It capture 110000 waveform in one second ans also output signal tell "fail" for every captured failed waveform. (small image, made with other oscilloscope connected to pass/fail output BNC)Here every acquired waveform pass in test. It capture 110000 waveform in one second. (small image, made with other oscilloscope connected to Trig/out BNC (output mode changed for measure speed using trig out signal. In this case pass/fail do not give signal out)Simply, with speed of Siglent this function is very powerful and useful as real tool for find signal anomalies.As noted previously, I have made full set of tests and it do all Mask tests with sama speed what it can capture without this function.

author: nctnico
author_rank: Super Contributor
timestamp: December 27, 2015, 10:29:56 am
content: Quote from: Performa01 on December 27, 2015, 01:17:00 amTektronix' TDS500/600/700 series are also 8 bit but they have a very usefull FFT feature (*) because there is no reason you need 12 bit for FFT to be useful! Same goes for Eres and averaging. Without long memory they are utterly useless because at some point you will want to zoom in on a long signal. You don't seem to perceive these as problems now but I'm quite sure you are going to see these limits as serious limitations of the SDS2000 in the near future when you are going to use it for real work. Having these limitations shows Siglent is still not on track with the firmware development of the SDS2000 and/or doesn't understand how an oscilloscope should work. The firmware update are just quick fixes to check items of the list and not to make the SDS2000 useful for any real work. The same goes for decoding: if that doesn't decode everything in memory then it is useless for any real work (been there, done that).edit: (*) Tektronix' TDS500/600/700 have selectable FFT length and can average the FFT result making it ideal to look at the frequency response of a system or filter. More bits are only required if you need more dynamic range but for many measurements the 40dB range you can get from an 8 bit system is more than enough.

author: Performa01
author_rank: Super Contributor
timestamp: December 27, 2015, 11:19:35 am
content: Another observation regarding pass/fail mode:When looking at the screenshots in my previous post, we can see where the last violation of the mask occurred. The violating part of the trace appears highlighted in front of the mask, and for the first test (with slow rise time) it can be seen on the screen during the test, which is no surprise since the violation happens permanently on every single positive going edge (Pass_Fail_SlowRise_60s_Hint)It is different for the second test though. As the violation only occurs once every 100000 signal periods, we really need to look close to spot the glitch every now and then – if we’re lucky. Usually we don’t see it. But on the screenshot it is clearly visible (Pass_Fail_Glitch_60s_Hint)The funny thing is that in this screenshot, the glitch occurred pretty much at the same spot where it was in the screenshot when I initially showed my test signal (by triggering on the sync signal of the glitch pulse generator).Now I wondered if every screenshot during the mask test would clearly show the violation or if it was just a lucky coincidence. So I ran the test again and took a number of screenshots at random times. And sure enough, none of them showed any mask violation, so I just had a lucky moment when I got the violation visible on that particular screenshot.I tried persistence mode, but this doesn’t appear to have any effect during pass/fail test. It would be a nice improvement if we could indeed have some persistence during the test. For instance, not updating the screen display after a mask violation for the time according to the display persistence setting would be great, as this would clearly show why the mask test has failed – so I will add that to my wishlist. Maybe Siglent could implement that eventually?

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: December 27, 2015, 12:18:14 pm
content: Quote from: Performa01 on December 27, 2015, 01:17:00 amOr so you hope!Don't forget that this scope is on the market for almost two years now, and still suffers from bugs that make it pretty useless for any real type of work.As nctnico said, Siglent is just ticking off boxes of bugs that are reported by users. It also appears that software testing is pretty much non-existent in Siglent (otherwise they would have found the problems before releasing the firmware, most bugs are hard to miss even if you tried!), and relies on users to do find bugs and report them back instead.In short, you pretty much bought a half-finished (ok, 70% finished) scope and agreed to work as a beta tester for free.And people wonder how Siglent can be cheaper than other brands...QuoteYes, the WaveAce is shit (guess who made them?) but there are many other alternatives which aren't.QuoteMost of them? The Keysight DSOX2k has a hires mode (10bit), as does the R&S HMO1000 (up to 16bit?). If I remember right even the Rigol DS2k/DS4k have some working hi-res modes.QuoteThat's nonsense, sorry. FFT does not need 12bit vertical resolution to "make sense", and is a pretty useful facility even on 8bit scopes, assuming of course the implementation isn't crap (like Rigol's limit of a few thousand points only) and works correctly (which it does on other scopes).And scopes like the DSOX2k or the R&S HMO1000 show that even in this class FFT doesn't have to be shit.QuoteReliability is certainly an issue, but frankly what accuracy do you expect from a scope with a timebase that is spec'd with+25ppm? Without an external clock reference (i.e. GPSDO) the accuracy will be limited by nature.QuoteY out was pretty much only available in a few specific Tek scope models and was also bandwidth limited, so it was only really useful for very specific cases.

author: Performa01
author_rank: Super Contributor
timestamp: December 27, 2015, 02:44:33 pm
content: Quote from: nctnico on December 27, 2015, 10:29:56 amWell, yes, it depends on the requirements. When I reviewed the SDS2000 signal generator some posts earlier, I think I’ve demonstrated very clearly what a well implemented FFT can do even with just 8 bits, squeezing out an impressive dynamic range of more than 60dB by use of appropriate resolution enhancement techniques. But then again, this was still not enough to verify the spectral purity of the SDS2000 signal gen, and it is not enough for many other tasks as well.But that wasn’t my point anyway. The point is that in my experience, only manufacturers that also make high resolution scopes have the inclination and experience to provide an FFT implementation that makes the most out of any existing hardware. Tektronix, as a well known manufacturer of RF gear, clearly have that experience. That’s probably why they knew that an 8 bit FFT wouldn’t cut it for many tasks, hence built a proper spectrum analyser into their MDO (mixed domain) series of scopes.Quote from: nctnico on December 27, 2015, 10:29:56 amWell, I think I have made very clear that having no long memory is a serious limitation and I really hope that Siglent is listening.I don’t perceive it as a BIG problem now, because normal and peak detect work as expected, with up to 35/70 Mpts of memory, and my point was that there are still scopes in the market, at a similar price point or even more expensive, that don’t have more than just a couple of kpts of memory to begin with, no matter what acquisition mode. The WaveAce was just one example, Tektronix has similar offers.And your assumption is wrong. I do use this scope for ‘real’ work (in my home lab), have used it even with the old V1 firmware, even though this wasn’t that great an experience.Personally, I would even consider it for professional work, even though it’s not mature yet and operators need to be familiar with its quirks – and by now, not all quirks are even revealed. But then again, other scopes have quirks as well and we can never blindly rely on what a scope is telling us. For instance, the scopes of some particular A-brand gave us regular headaches with their intractable trigger system, which I consider much more a show stopper than any flaw on the Siglent.Average acquisition mode is a nice feature to have, but certainly not essential for most tasks. Analogue scopes generally don’t have an average mode, yet engineers could make do with that for many decades.Eres is a mixed bag anyway, because it inevitably limits the bandwidth depending on the actual sample rate. Sure, this might not be a problem in many cases if we had the full memory available, hence a constant high sample rate up to slow timebase settings, so I do hope Siglent will cure that eventually.Still, if we really need high resolution, nothing can beat getting a proper 12 bit scope, which does not only give us the higher resolution, but also the accuracy, and the bandwidth doesn’t change with sample rate either.Quote from: nctnico on December 27, 2015, 10:29:56 amSorry, just because with the old V1 FW it didn’t meet your particular needs, claiming it isn’t useful for ANY real work is blunt bashing, since the basic functionality is sound. Only if I had paid two (or more like three with all the options) times as much to get a 300MHz/4Ch. mixed mode scope from some A-brand, I would complain loudly, but since I preferred staying cheap, I just have to be patient – as long as Siglent cares to improve their products based on user experience.Quote from: nctnico on December 27, 2015, 10:29:56 amWho says that it doesn’t?All I can tell so far is that it works just like any other MSO or LA. It captures screen by screen at the chosen timebase, and if this results in thousands of packets per screen, one will of course not see any meaningful decoding without stopping acquisition and zooming into the acquired data.This even works in history mode, which essentially is segmented memory anyway. There are 14 Meg available when using digital channels and as always with segmented memory, we can chose to have 14 Mpts and only one segment if we’re interested in lots of data for just one single trigger event, or e.g. 416 segments with 70kpts each if we’re interested in analysing lots of subsequent acquisitions (with still plenty of data for each trigger event).

author: nctnico
author_rank: Super Contributor
timestamp: December 27, 2015, 03:15:41 pm
content: The V2 firmware doesn't look like it is much better than the V1 firmware. Just more things plastered over. If you want to use an oscilloscope's FFT function to check the spectral waveform purity of the signal generator than you are clearly using the wrong tool. Either way the value for money the SDS2000 offers just isn't good because a lot is severely limited at best. You can buy a used DSO for the same amount of money which has proper FFT and works as advertised. The added value of the SDS2000 is in the MSO, protocol decoding and advanced features but it is those that cause most of the headaches. If I didn't need protocol decoding I'd never bought the SDS2000 to begin with! Also your remarks about averaging and high res being OK with a short memory is nonsense. They are very handy to clean a signal up so you can make accurate cursor measurements. I made good use of that in one of my recent projects on a trace which was several seconds long.Still I'd like to see how the protocol decoding works in the V2 firmware and whether you can zoom (using the s/div knob) into the bits of a message without losing the decoding. And does zoom mode work together with decoding in the V2 firmware?

author: Performa01
author_rank: Super Contributor
timestamp: December 27, 2015, 05:13:33 pm
content: Quote from: Wuerstchenhund on December 27, 2015, 12:18:14 pmWhat bugs are you talking about, that make it ‘pretty useless for any real type work’?I have used the SDS2000 to troubleshoot, repair and redesign some older test gear, including some high precision stuff, and as a DSO, it didn’t let me down. I just had to use a separate LA as the digital channels were not working with the initial V2 beta firmware.Other brands are big companies that have built gear for decades and have a big R&D department with lots of firmware developers. The firmware for a complex piece of gear like a modern MSO isn’t that easy to develop from scratch with just a handful of people.QuoteWhat’s left, if nobody else does?Siglent claims to aim for making affordable test gear available for everyone. Many private users out there certainly welcome that. Do we reach that goal by just bashing Siglent for some immaturities in their firmware, or is it more likely to achieve something by reporting any bugs we find?I could understand if people get angry for instance about bugs in a Rigol 4k, as these start approaching the prices of A-brand scopes in the same class, also with the various software options. If we have to pay big money like for an established A-brand, we expect a mature product indeed.QuoteOh, of course. If you you’re willing to pay 5k or more for the basic scope, plus another 1k for each and every software option, even if it’s a serial decoder for just a single protocol, and still make do with relatively short memories, than I’m sure you’ll find ‘many other alternatives’.QuoteMaybe. I have the impression that resolution enhancement wasn’t that common until recently.QuoteFor spectrum analysis, I personally just cannot think of too many use cases, where I would want to have less than at least 70dB of dynamic range.QuoteI don’t think I expect something unreasonable. Every single quartz crystal oscillator I’ve used so far was pretty much spot on within a couple ppm of its nominal value at room temperature, despite the specs that usually say +/- 100ppm. So it is somewhat strange if an oscillator in a scope is close to the limits of its accuracy spec. right from the start.The much bigger problem is the lack of resolution anyway, due to its not implemented as a reciprocal counter, which is all the more incomprehensible, given all the computing power in such a scope.QuoteI don’t think I expect something unreasonable. Every single quartz crystal oscillator I’ve used so far was pretty much spot on within a couple ppm of its nominal value at room temperature, despite the specs that usually say +/- 100ppm. So it is somewhat strange if an oscillator in a scope is close to the limits of its accuracy spec. right from the start.The much bigger problem is the lack of resolution anyway, due to its not implemented as a reciprocal counter, which is all the more incomprehensible, given all the computing power in such a scope.QuoteTo put it in your own words: that’s nonsense, sorry.But on this topic I discovered something interesting:http://blog.hameg.com/?p=622So while I thought Y-out has gone with the introduction of digital scopes, apparently Hameg/R&S provide a Y-output (again) at least for their HMO series. That’s great news, and makes these scopes attractive for people who want an accurate trigger frequency display. And it is exactly like it used to be with the analogue scopes – the y-output follows the triggered channel. And no, it was NOT bandwidth limited at all.I have no doubt though, that the built in frequency counter of an HMO has true 6 digits of resolution and would be fairly accurate (like even on the ancient Rigol 1054E), so there is much less need for an y-out just to feed a proper external frequency counter anyway.

author: nctnico
author_rank: Super Contributor
timestamp: December 27, 2015, 05:28:06 pm
content: Quote from: Performa01 on December 27, 2015, 05:13:33 pmThat depends on your definition of recently. The Tektronix TDS500/700 series which was introduced around 1990 has high-resolution mode as standard.

author: Performa01
author_rank: Super Contributor
timestamp: December 27, 2015, 06:36:27 pm
content: Quote from: nctnico on December 27, 2015, 03:15:41 pmOh? I’m a bit confused right now. What do we use in order to check the spectral purity of a signal? A spectrum analysis tool, don’t we? And what is an FFT analyser then?So you probably meant to say I should have used a _proper_ spectrum analyser instead, right? You’re absolutely correct about that – I just don’t have one here at the moment (and the one I have in my second lab only starts at 500kHz, so there would have been a gap anyway).So you’re basically suggesting that FFT on an 8 bit scope is not the right tool to do a proper spectral analysis. That’s certainly correct, mainly because of the severely limited dynamic range.And that’s exactly what I said all the time.QuoteIs it really that limited? Just because average and Eres modes aren’t very useful right now? And just because of the FFT? Why do we need FFT on a scope anyway, when you yourself stated it’s not the proper tool for doing spectrum analysis?QuoteThat’s fine, but not everyone is like you.There are also folks like me, who want a scope with reasonably high bandwidth, high signal fidelity and a reliably working, jitter-free trigger system. And deep memory of course, so we don’t run into aliasing troubles when looking at signals that contain LF and HF components at the same time.Ah – yes, we also want a reasonable high waveform update rate, so that we can see what’s going on with a dynamic signal.All the additional bells and whistles are nice, but it’s not the world if there are still some flaws in them.Particularly for protocol decoding I have no problems to stick with my LA if needed. The nice thing of an MSO is that it’s so easy to correlate analogue and digital signals, where digital in my case mostly means control signals and not a serial bus, even though this would certainly also be very useful for some cases, e.g. troubleshooting A/D or D/A converters with a serial interface.QuoteThank you. Where and when did I ever say it is ok?The best thing I’ve ever said about average mode is that it’s kinda usable, but would be much more useful if only we had more memory available. What I said is that we should be able to live with the slow wavefrom update rate, as there is no hardware support available in this mode.For Eres mode, I’ve even stated that the way it is implemented now I cannot think of any useful application. But on this one I was not quite right, because it can still serve as a noise reduction tool for non-repetitive waveforms. But having said that, please don’t argue sometimes in the future that I’ve made a remark that Eres is ok, ok?What I finally said is that there are still scopes in the same price range that do not have long memory in the first place.QuoteYes, as it is now you couldn’t use it for that, except when the signal frequency stays below some 250Hz.QuoteI’ll certainly do that, but I have to set up something that generates a serial data stream first. Unfortunately I don’t have anything ready to use at my hands at the moment.

author: nctnico
author_rank: Super Contributor
timestamp: December 27, 2015, 06:54:04 pm
content: Quote from: Performa01 on December 27, 2015, 06:36:27 pmStop moving goal posts / twisting what I wrote! A good LF sine wave generator will have a harmonics well below 40dB so it rather is obvious that an 8 bit FFT isn't going to cut it but an 8 bit FFT is still perfectly useful for checking filters, system bandwidth, distortion, EMC issues, etc. Your claim FFT is on an 8 bit scope is useless is just nonsense.QuoteWith those requirements the SDS2000 simply is the wrong choice; a second hand DSO from an A-brand would be a much wiser choice! How many hours did you waste doing tests on your SDS2000? If you would have put those hours to better use you may have made enough money to cover the price difference between the SDS2000 and a scope which works.

author: smarteebit
author_rank: Contributor
timestamp: December 28, 2015, 08:02:40 am
content: Quote from: nctnico on December 27, 2015, 10:29:56 amFor Eres I agree with you, but for averaging why is long memory so important? It must be a periodic signal to apply the averaging, a single peroid contains all the information you need. I think in most of cases kpts memory and >60 wfm/s update rate are enough for average mode.

author: nctnico
author_rank: Super Contributor
timestamp: December 28, 2015, 10:26:15 am
content: A frequency sweep is also periodic!

author: smarteebit
author_rank: Contributor
timestamp: December 29, 2015, 01:02:57 am
content: Quote from: nctnico on December 28, 2015, 10:26:15 amI don't think it is wise to use averaging to observe a frequency sweep signal. Have a try.

author: nctnico
author_rank: Super Contributor
timestamp: December 29, 2015, 09:27:02 am
content: Quote from: smarteebit on December 29, 2015, 01:02:57 amUse the sync output of the generator as a trigger and you'll be able to average a frequency sweep on a long trace without problems.

author: Performa01
author_rank: Super Contributor
timestamp: December 30, 2015, 07:22:23 am
content: Horizontal PositionJust want to point out something that regularly ticks me off – it’s the horizontal position adjustment on many DSOs – not just Siglent.Let’s have a look at the vertical position first.I set it 3 divisions down the centre, which corresponds to -60V in the 20V/div vertical gain setting (V_Pos_20V)Now when I ‘zoom’ into the waveform vertically, by increasing the vertical gain to 2V/div, everything works as expected. The vertical position remains unchanged and corresponds now to -6V, as it should be (V_Pos_2V)Now let’s do something similar with the horizontal position.I set the position 2 divisions left of the centre, which corresponds to -1ms at a 500µs/div horizontal timebase setting (H_Pos_500us)When I ‘zoom’ into the waveform horizontally, by lowering the timebase to 200µs/div, the result is quite different to the vertical settings: now the trigger point moves to the left and is now 5 divisions left the centre (H_Pos_200us)Of course, making the timebase even faster would move the trigger point out of view.This behaviour is rather annoying and inconsistent with the vertical position.Both, x and y position knobs are labelled ‘Position’.For both, the screen display doesn’t show a position, but an electrical quantity, volts for vertical and seconds for horizontal. But in the case of vertical, the position remains constant and the displayed volts offset changes according to the vertical gain setting, whereas for horizontal, the position changes and the displayed time offset (called ‘Delay’ here) remains constant.We often want to zoom into a waveform horizontally, but at the same time we don’t want to change the position of the trigger point on the screen.I know, many scopes (but not all!) do it like the Siglent, but that doesn’t make it right in my book.Maybe we could get a compromise in one of the next firmware releases: the horizontal menu is pretty empty anyway. Why not include a menu item to chose between constant screen position (as I think it should be anyway) and constant delay (as it is now)?

author: nctnico
author_rank: Super Contributor
timestamp: December 30, 2015, 07:47:51 am
content: On many (higher end) DSOs you can adjust the horizontal position. In my case I often have the trigger point set somewhere in the left part of the graticule because in 90% of the cases you are not interested in what is before the trigger point.

author: tautech
author_rank: Super Contributor
timestamp: December 30, 2015, 08:03:57 am
content: Funny isn't it how what some of us accept as normal behaviour drives others to despair.As you say most of us have experienced this, I have many times and the normal workaround is to return the H position to zero and readjust to suit the job at hand.It could well be a handy feature you ask for, just as you say closer examination of one part of a waveform with a H offset WILL have the waveform off the display at faster timebase settings.Yes, there's heaps of room in the Horizontal menu to incorporate such a feature.Which other brands have a user definable horizontal position?Anyway I'll vote for it, who else?Quote from: nctnico on December 30, 2015, 07:47:51 amBrands? Models?

author: rf-loop
author_rank: Super Contributor
timestamp: December 30, 2015, 08:17:48 am
content: Setting delay and setting horizontal position is bit different. Because setting delay from center line moves horizontally. But this is based to time, not based to distance in divisions or millimeters etc. You set TIME position related to center line.Now if we change time scale of course horizontal position moves because we have set how far in time we want be from center line.There need be one setting more. Lock trigger position to the current user adjusted position on the screen independent of t/div scale and then same function need include swap between delayed time position and this trigger position....it need just one button... or there can even use long push and short push or ... this need carefully design for good useability.Also more wishes. Add one feature. When zoomed and trig position is horizontally where ever is... one button: set zoomed window center to trigger position. My fingers are tired to turn these adjustments.......also many adjustments are frustrating slow and I hope they develop FW better also for these small things (but honestly it can also tell that overall Siglent have developed themselves lot of... but always..developing road is endless.). Try turn example trigger holdoff adjust from minimum to example 500ms.. Do Siglent think I will employ one secretary who turn this knob so that I can go to coffee for this waiting time. These kind of adjustments need be flash speed if people do work for earn money with using instruments. Why they do not think themselves how instruments UI need build. Peoples who have only sit in school whole life and without any real knowledge and enough experience how to use test and measurements equipments in practice for real working can not design UI. Period. And Siglent is not in this club alone and not at all poorest member!Lets money talk... What ever scope, Rigol, Siglent or xxxx If I need every work day use extra time for nothing, just loosing time for turning some slow adjustments extra 10 minutes when this can do in 15 seconds if functionality is designed right. Every year I loose more than one these kind of oscilloscopes price just alone for this one thing. If these kind of things are many... and my working power decrease say 20% due to instruments poor useability... hobbyist is different. He can think and talk with his wife...oh well...hobies take time..

author: nctnico
author_rank: Super Contributor
timestamp: December 30, 2015, 03:00:13 pm
content: Quote from: tautech on December 30, 2015, 08:03:57 amAFAIK on all Tektronix and Yokogawa scopes the trigger position can be adjusted freely. My Agilent DSO7000 allows to select left, centre or right but I would expect the lower end models to also have this feature.

author: Performa01
author_rank: Super Contributor
timestamp: December 31, 2015, 08:31:00 am
content: Serial Decoding (DSO) - UARTAs the heading suggests, this is about serial protocol decoding with the analogue channels.I will not be able to test all the decoders, but will review the UART protocol for a start. It’s not only the oldest standard, but also still a very common one – almost every microcontroller comes with UART hardware built in.Historically, there is a number of possible configurations, regarding the number of bits (5-9), frame format (1, 1.5 and 2 stop bits), parity (even, odd, none) and handshake. For my test, I’ll stick with the simplest (and most common) setup:8 data bits, one stop bit, no parity, no handshake (which is irrelevant for decoding anyway).Idle level is always high, unless we have to deal with an inverted UART signal.The industry standard speed setting is still 9k6 baud, but I wanted to go a little faster than that - and by that, I already found some serious bug…The microcontroller used for generating the serial data stream has a rather primitive baud rate generator that would not be able to generate more than 38k4 baud with decent accuracy (at 20MHz clock).Initially, I wanted to use 115k2, where the micro would actually generate 113636 baud, that’s an error of -1.36%.In order to make sure my test isn’t flawed by any major timing inaccuracies, I wanted to set the scope to exactly that baud rate, but it turned out to be pretty much impossible (UART_Custom_Baud)Bug Alert:The custom trigger setting is unusable. I tried to set 113636 baud for several minutes before I finally had to give up. Adjustment seems to work initially, but because of the poor responsiveness of the select knob it would take some time to get there anyway. But at a certain point, it starts making big jumps and the values go all over the place. For instance, at about 80000, it suddenly jumped down to 70000, than back up to 90000 and then to 140000 with one big leap. When I tried to get back down, it would eventually jump back from 122000 to 300. I tried again to go up to 113000, but to no avail – after approaching 80000, values start to jump randomly and go all over the place.After that experience, I decided to stick with 38k4, which my little micro can generate with just 0.16% error. This is a standard baud rate, consequently one of the predefined settings on the scope (even though not visible in the screenshot, these are available down to 600 and also 300 isn’t a problem, as this is the lowest custom setting).The signal setup is Ch. 1 for RX and CH. 4 for TX. Since I don’t actually have any valid RX signal, it would be nice if I could disable decoding for RX in the channel selection menu. But then again, in any real application we would hardly have an UART communication in just one direction (UART_Signal_Setting)For the initial test, I’ve set a standard trigger on the falling edge of the TX signal (Ch. 4). After switching ‘Display’ on, we get the decoded values at the bottom and in a list overlay on the top half of the screen (UART_Decode_full_14)At the bottom of the screen we have two lines of decoded values. Since Ch.1 carries just a random signal, we can’t get any meaningful values and the decoder doesn’t even detect anything before the trigger position (which sits at 50% of the screen width).With serial decoders active, we have a memory limitation once again – we cannot have more than 1.4/2.8 Mpts of memory (UART_Decode_Memory)Why this limitation?But I guess I know the answer – it’s probably all about processing power, as the waveform update rate drops to just ~1/s when decoding is active. This would certainly get worse with more memory…Switching Ch. 1 off makes the unwanted line of decoded RX values disappear (UART_Decode_full_4)Now we only have the TX decoding left, but of course we cannot see anything, as there is a total of some 1000 values on the screen.But we also have the list on the top half of the screen, which shows the values for RX/TX together with individual timestamps and error information. The list size can be configured from 1 to 7 lines and I’ve set it to the maximum right from the start.Complaint:There is so much space in that list – why on earth do we only get hex and cannot have decimal and ASCII decoding as well? This would make it s much more useful.To verify the validity of the decoded data, my test data is configured as a stream of packets, 16 bytes each, which just contain a counter running from 0 to 0xFF. So the first packet contains the numbers 0 to 15, the second one 16 to 31 and so on. After the last packet (240 – 255) it starts over again at 0 – 15.As we can see in the list, the first four decoded values aren’t correct, quite obviously the decoder just starts with the first captured data and doesn’t seek for a proper start condition first. But at least it gets in sync eventually, so everything looks fine after the 4th decoded value.Now we can scroll through the list to inspect the other values, which can be a tedious task for that many values as there is no acceleration for the select knob – but at least it doesn’t do funny things like jumping around. Instead it has something else to offer (UART_Decode_Full_Scroll)Instead of moving through the list, as we’d expect, it highlights any line we’ve ever selected, plus showing some funny artefacts in the RX and TX ERR columns.Bug1:The selection knob really is a pain to use. It either does funny things in a failed attempt to respond to the speed of turning it, or it doesn’t change it’s behaviour at all, making it almost impossible to get through a longer list or a larger number of selections.Quite obviously there is not one central driver for the rotary encoder with working parameters for base sensitivity and acceleration, that hopefully would be tested to be fool proof in operation, but each part of the scope seems to use its own encoding routine and so we don’t get a consistent behaviour throughout the instrument. This problem certainly has to be addressed.Bug2:The list navigation basically works, but it clearly shouldn’t look like this. The arrow in the leftmost column should only be in the line currently selected, and all the shading and funny artefacts shouldn’t be there, should they?After a while of twiddling with aching fingers I got to the point where my counter overflow occurs. We can see this happen between decoded values #212 and #213 (UART_Decode_Full_Rollover)After even more twiddling and a serious amount of time, I finally managed to reach the trigger position, where the timestamp changes sign (UART_Decode_Full_Trigpos)Now instead of just looking at the decoded values in the list, we want to see them correlated to the actual waveform. We can do this by lowering the timebase setting and then use the horizontal position control to navigate through the data (UART_Decode_Detail_0us, UART_Decode_Detail_200us)The list display only shows what’s on the screen, which is a good thing given the poor response of the select knob. The problem with this is that the correlation to the total captured data is lost, as the list now starts with number one again and we cannot know how this relates to the numbers in the full list.An alternative (and probably better) approach would be to always have the full list and we could select a value in it and the corresponding waveform gets automatically centred on the screen. This way we wouldn’t need the horizontal position control at all.Another way to look at the details is using the Zoom function (UART_Decode_Zoom)This works beautifully now. The list starts at 1 again, hence still doesn’t correlate to the total data, but other than that everything works as expected. We can use the horizontal timebase and position controls to navigate through the data.There’s a lot more to serial decoding (and triggering!), but this review is already long enough so I’ll stop it here in order to draw a first conclusion.Conclusion:Serial decoding certainly works – at least for the UART, that has been tested here – and is already quite usable, but still has a number of bugs and flaws that need to be addressed.In general, the Select knob is a pain to handle and it behaves quit differently for different applications within the scope. This really needs a central encoder driver with proper sensitivity/acceleration parameters, properly tested to be effectively and reliably working. It’s these little things that can completely spoil the usability experience with any instrument.The list display navigation needs to be fixed. Multiple arrows, highlighting like a multi-selection plus some artefacts look weird and lead to confusion.The list display should contain decimal and ASCII representation of the data together with the hex value that we already have.It would be nice if the numbers in the list of decoded values would always stick with the decoded value, i.e. the list would not start with 1 again in zoom modes, but keep the numbers of the total capture for the decoded values shown.EDIT: Configurable decoder list size corrected to 1 - 7.

author: Performa01
author_rank: Super Contributor
timestamp: December 31, 2015, 08:55:22 am
content: Quote from: tautech on December 30, 2015, 08:03:57 amIt certainly needs not be a high end scope.PicoScope for instance, who is a reputable UK manufacturer of USB scopes up to the >10k price range, have this for all their scopes. You don't set a horizontal position, but a pre-trigger range expressed in 0 ~ 100% of the horizontal screen width. That's the logical and intuitive way to do this and is in accordance with our experience with analogue scopes, where the trigger position doesn't change with timebase, no matter what we've set the horizontal position).

author: nctnico
author_rank: Super Contributor
timestamp: December 31, 2015, 09:50:23 am
content: Quote from: Performa01 on December 31, 2015, 08:31:00 amThe Agilent DSO7000 works this way which is a real blessing when looking for a malformed packet. The waveform tracks the selected message from the list (which shows all the messages in the memory and not just what is on screen).All in all the decoding on the SDS2000 is still crappy (as I feared). How on earth are you going to find a missing/malformed bit or message? BTW I have pointed Siglent to Youtube videos on how decoding should work early in 2015 but appearantly they are not willing to learn!

author: Performa01
author_rank: Super Contributor
timestamp: December 31, 2015, 10:17:30 am
content: Quote from: rf-loop on December 30, 2015, 08:17:48 amI totally agree.The PicoScope I've mentioned before certainly has both settings at the same time - pre-trigger range (trigger position)andtrigger delay. The latter I've never used so far, because thankfully I was always able to set up a trigger condition closely related to the signal I wanted to see. So I thought trigger delay would generally not see much use (except maybe analogue video signals when no dedicated video line/field triggers are available, but that should be a real niche application nowadays), hence I could make do with just having to switch between the two in the horizontal menu.I would even be happy with a soft button in the horizontal menu, where we could set the trigger delay by means of a (hopefully properly working by then) select knob, just like the holdoff value in the trigger menu. But the main use of the horizontal position control should be to set the screen position of the trigger point, that would not change with the timebase.

author: Performa01
author_rank: Super Contributor
timestamp: December 31, 2015, 12:25:32 pm
content: Serial Trigger (DSO) - UARTI’ve still used a conventional edge trigger for the review of the serial UART protocol decoding. Now let’s see how well the serial UART trigger works.The setup appears to be independent of the serial decoding, so we need to repeat all the settings here, such as channels, trigger levels, idle level, bit order, plus the specific UART protocol settings (number of bits, stop bits, parity, baudrate).We can trigger on several conditions, for instance on the start of a frame (UART_trig_start)Of course this will trigger on the start of any frame, so we get just a random portion of our data stream. We can also trigger on the stop condition (UART_trig_stop)That doesn’t make much of a difference, other than the trigger fires just one bit clock earlier, i.e. on the stop bit, that is immediately followed by the start bit within one packet.Apropos packets: in the previous screenshot we can see the transition between two packets, as I deliberately programmed a little break between them. It is the signal staying idle for some 240µs on the transition from 0xef to 0xf0.We can trigger on specific data as well, unfortunately a single data item only, not a complete message. The following screenshots demonstrate this by triggering on0x00 = the start of the first packet0x1f = the end of the 2nd packet0x20 = the start of the 3rd packet(UART_trig_data_0x00, UART_trig_data_0x1f, UART_trig_data_0x20)There is also a parity error trigger, and of course it never fired in my test setup, since parity isn’t even enabled. I didn’t test this any further as I couldn’t be bothered to program the UART in my micro ina way that it would generate parity errors sporadically – I’m just willing to believe that this trigger condition works, provided parity checking works in the first place. This I’ve also not tested yet, but then again, most UART connections only run over short distances nowadays and so we don’t usually configure them with parity – just like for SPI busses, where parity checking isn’t even an option.ConclusionThe serial UART trigger works just fine, though it would be nice to be able to trigger on more than just one single data item. Setting up a list of, say, up to 8 data items that have to occur in the data stream in sequence in order to fire the trigger would certainly be helpful in finding a particular message on a busy data connection.

author: Performa01
author_rank: Super Contributor
timestamp: January 02, 2016, 01:01:45 pm
content: Serial Decode (DSO) - SPISPI is a synchronous serial transmission standard, so we would expect decoding to be a fair bit easier than the asynchronous ones, like UART, where the bit clock has to be recovered from the data stream in order to decode it.There are 4 SPI modes for data setup and sample at any combination of clock polarity (which determines the idle level) and clock phase (leading or trailing edge).I’ve set up the most common SPI mode 0, which means clock idle level is low, hence positive clock polarity and data is set up on the falling (trailing) edge and sampled on the rising (leading) edge of the clock signal.The data length can be set to anything from 4 to 96 bits, but 8 bits is the most common configuration, and I’ve used this one too.Interestingly, the SPI decoder of the SDS2000 doesn’t provide a configuration for the clock polarity (or idle level), which might make it a bit more difficult for the decoder to get in sync at the start of a packet. At least there is a toggle for selecting the clock edge for sampling, which just distinguishes between SPI modes 0/4 (rising) and 1/2 (falling). So I chose the rising edge (SPI_Decode_Setup_CLK)As my little micro provides almost no hardware support for SPI, I stick with a clock of only 100kHz, but I also have no doubt that speed doesn’t matter for this test as long as the sample rate is kept about an order of magnitude higher than the SPI clock.In contrast to UART, data channels can be disabled in the SPI decoder menu, even though the menu item says ‘CLOSE’ whereas I would think ‘Disable’ would be more descriptive (SPI_Decode_Setup_MISO)For the initial tests I use negative edge triggering on the slave select signal, which is labeled ‘CS’ in the SDS2000 decoder menu and the ‘~’ (C language notation for bit-wise inversion) is used in the menu to describe an inverted signal (SPI_Decode_Setup_CS)Complaint:While the SDS2000 keeps most settings after a restart, it does not preserve the threshold levels for the various signals. In my setup, threshold levels reverted back to 16V after every restart and I had to set them again to 2.5V for each individual signal (SCK, MOSI, CS).At a timebase setting of 100µs/div we can see a complete packet with 16 data items. Decoding appears to work and only the MOSI line of decoded values is displayed at the bottom of the screen, just as expected. The data look correct, just the first value (0x50) is already a little too wide to fit the available space and the incomplete display is indicated by a red dotI’ve set the trigger point to about 7% of the screen width, so the 2nd list entry corresponds to the first data after the trigger point, with timestamp 0.00µs (SPI_Decode_100us_7%)The first decoded data item at -98.00µs is faulty (should be 0x4f), as is to be expected, since the packet is truncated. But why on earth is it displayed in the first place? The decoder knows that we are looking for 8 bit data, so why display something what looks like a valid decoding instead of something like ‘6 error bits’, as other protocol decoders would? Even displaying nothing at all would be better than filling the list with invalid data without any hint that they aren’t valid.What happens if I run the test at 5ms/div in order to capture some 50 packets (800 data bytes) at once? With the trigger point set just 200µs apart from the left screen edge, we get the following picture (SPI_Decode_5ms_0%_1)The first data item after the trigger is now the 4th item in the list and data appear to be correct here, but everything else? Oh boy, what a disaster!First look at the timestamps in the list.We have two entries with each -100.00µs and 0.00µs respectively, which might be a hint that the actual resolution of the timestamp is worse than 100µs, even though the display suggests a resolution of 10ns and the current sample rate of 20MSa/s allows 50ns after all.Then what happens after the 4th entry? Timestamp suddenly jumps up to the maximum value and says 69.8ms for all the 860 remaining entries in the list!And what about the decoded data line at the bottom of the screen? It says just ‘0xe0’ for a total of 864 bytes on the screen!Scrolling thorugh the list, data is basically correct, but shows an unjustified 0x00 decoding between packets, except for the transition where the data counter rolls over from 0xFF to 0x00. So it seems it doesn’t happen if the following value after the short break is actually zero. To illustrate this, I show screen shot examples for two transitions (SPI_Decode_5ms_0%_17, SPI_Decode_5ms_0%_34)Just for completeness I also show the end of the list, that contains a total of 864 entries. The last complete packet ends at line 859 and the data is 0x2F, then comes the already familiar extra 0x00 decoding, followed by 4 items that are just garbage. It almost looks like the decoder keeps working a little beyond the end of the acquisition buffer on some data, that have not actually been captured (SPI_Decode_5ms_0%_858)All displays show just some random number for the bottom line decoding.Can we try to find the problem? Let’s just lower the timebase (in stop mode, as I’ve moved over to single shot capture already) to 100µs/div in order to see a complete packet, just as we did before – but all the errors we’ve seen so far are there again (SPI_Decode_5ms_100us_D600us_1)The timestamps now jump to just 1.30ms, but the data is correct except for the extra zero byte, that clearly isn’t there when looking at the data traces on the screen. There are double lines because of the peak detect mode, but even though it might not look pretty, it has absolutely no impact on the decoding. Just to make sure, I’ve tried it in normal acquisition mode as well, without any different results. The bottom display line keeps saying ‘0xe0’ and of course the multi selection, shading and artefacts in the list are there, just as already mentioned in the UART review.Just for completeness I’ll also show the end of the list where we see another extra zero decoding, once again not warranted by the signal traces as they appear on the screen. Neither at the start nor at the end of the packet is the MOSI line low at all, let alone for full 8 clock periods (SPI_Decode_5ms_100us_D600us_13)Even though no further tests would be necessary in this situation, I still tried zoom mode. Even though I’ve already seen this kinda working sometimes, it is a complete mess right now. The decoding line at the bottom of the screen shows ‘0x00’ and the list is in accordance with that for a change (SPI_Decode_5ms_Zoom_100us)It’s the same for serial SPI triggering, which also doesn’t work.I could not be bothered to post a dedicated review on this, so I just want to point out that serial SPI trigger on 8 bit data only works for the upper 4 bits, whereas the lower nibble always is treated as zero, no matter what the actual setting is. And for the entire trigger word, the don’t care setting (‘X’) is ignored and treated as zero. So this is completely unusable as well.Apart from the fact, that the scope should never behave like this, no matter what signals are thrown at it, there still remains the question if there’s something wrong with my signal? I think the fact that the list display is basically correct, but the timestamps and the decoding line at the bottom of the screen are not, already is a strong indication that there’s nothing wrong with the signals after all.Just to be sure, I have hooked up an LA with serial protocol decoder in order to verify that everything is fine with the signal. And the results indicate that it is indeed! All the data is correct and there are no extra zero data items between packets. And this is with a sample rate of just 1MHz!This decoder also displays the first (truncated) packet that is not in sync, but it clearly indicates that there were 2 bits missing on the last data item, so we can know that the entire packet is invalid (SPI_Data_Verification)Conclusion:SPI decoding is totally unusable and I cannot even begin to list all the bugs I’ve found during my tests. Well, it’s more than just bugs, it simply doesn’t work. SPI trigger doesn’t work either.This is clearly a case where nobody could claim this part of the scope has ever been tested, other than maybe one single message at one fixed timebase setting, just like my very first scenario.It is very bad practice, to include totally untested pieces of firmware with an official release.

author: nctnico
author_rank: Super Contributor
timestamp: January 02, 2016, 02:36:58 pm
content: returnreturnreturnreturn

author: Fagear
author_rank: Regular Contributor
timestamp: January 03, 2016, 10:15:47 pm
content: Quote from: rf-loop on December 30, 2015, 08:17:48 amMay I add a little to this topic?As owner of Rigol DS2072A I can confirm that it can fix trigger position on whatever place on the screen. Just set "HorRef" as "Trig Pos" in Horizontal menu to lock it.Or you can also set it as "User" to set "zoom point" independently at any point on the screen (not locking to the center of the screen or trigger position). DS1000Z cannot do it though.

author: Mark_O
author_rank: Frequent Contributor
timestamp: January 04, 2016, 04:54:12 am
content: Thanks for the extensive breakdown. One error I did want to point out though...Quote from: Performa01 on December 31, 2015, 08:31:00 amThis isn't the fault of the scope OR it's decoders. It is the (expected) result from your setting the triggering on an arbitrary edge. I believe if you adjust the triggering to UART mode, that your results will fall into alignment properly.[Don't feel bad... I made the same mistake initially, when I started testing the decoders on the SDS1000X. If it never managed to 'sync up' properly, and we had nothing but garbage, then the operator error would be obvious. Since it eventually does sync, we overlook the fact that we didn't set it up properly in the first place.]

author: Mark_O
author_rank: Frequent Contributor
timestamp: January 04, 2016, 07:41:02 am
content: Quote from: Performa01 on January 02, 2016, 01:01:45 pmBelieve me, I feel your pain on this. I've been running a 1000X through a battery of tests for some time now, and SPI was one of the first things I looked at. And many of the same glitches and anomalies were present there as well (with edge-triggering). That would tend to confirm the hypothesis that the two scopes share much the same core code-base. As would the fact that most (not all) of the other problems you've reported from your extensive testing also appear in my list for the 1000X too.However, unlike with your 2000(X), the SPI situation improved quite a bit when I changed from an edge-triggered mode to SPI-triggering. I was surprised to hear your report that it made no difference. So it's possible that some improvements on the 1000X side simply haven't made it over to the 2000X yet.QuoteI believe that is correct. I ran SPI tests from 10kHz to 14 MHz (using an embedded comms channel on an NXP chip), with both 8-bit and 16-bit message "words", and as long as the sample rate remained at least 4x the bit-clock, the 1000X handled it as well (or as badly).QuoteThis wasn't true on the 1000X, even on the earliest of the 3 Releases I have been working with. I set up match patterns spanning 4, 8, and 16 bits, and all were observed properly. And X was never treated as matching just "0". And never did I observe a situation where multiple Cursor pointers in the List view were lit up simultaneously.I mention this mainly to give you some hope, because the code appears to still be going through some significant transformations. Which hopefully should eventually appear for you on the 2000(X) platform.QuoteWhile I don't think that SPI decode is unusable on the 1000X, I do have to agree that there are too many quirks, anomalies, and glitches to accept it as a reliable debug-platform, at the moment. And the number of problems, which as you commented strongly suggest an inadequate level of in-house testing, makes the job of evaluating or reviewing the product far more difficult than anyone might anticipate, for a released product.So I have a lot of respect for the amount of time you have invested in your exploration of the V2 software releases for the SDS2000(X). I'm not sure where you've found the time to perform all the tests and write them up!I'm having trouble just keeping up with reading them all!But I am sure it is providing Siglent with a wealth of extremely valuable information, which should enable them to quickly focus on correcting the issues.[NB: you mentioned about the List size for Serial decodes..."The list size can be configured from 4 to 7 lines and I’ve set it to the maximum right from the start."Are you sure that isn't from1-7? The 1000X lets you drop it as low as 1 line (saves space), and the User Manual for the 2000X indicates 1-7 as well.]

author: Performa01
author_rank: Super Contributor
timestamp: January 04, 2016, 10:07:26 am
content: Quote from: Mark_O on January 04, 2016, 04:54:12 amThanks a lot for your replies – it is nice to see another user care for the topic and makes me feel not so alone nowRegarding edge triggering on an UART signal, you’re perfectly right and it’s probably just the way I put it was a bit misleading. I certainly didn’t expect the decoder to get in sync properly in the middle of a packet – that’s why I’ve set up this test with a series of packets (with small periods of idle level between them) instead of just one endless stream of data in the first place.I personally cannot think of a way to reliably detect the start of a frame when decoding starts in the middle of a stream.When using the UART trigger, there are no invalid packet fragments (as can be seen in the screenshots of my review of the UART trigger) – most of the time, that is. I have to make a reservation here, as it is obvious that the trigger would still fire if the incorrect decoding from any initial out-of-sync packet matches the trigger condition by accident.

author: Performa01
author_rank: Super Contributor
timestamp: January 04, 2016, 10:22:58 am
content: Quote from: Mark_O on January 04, 2016, 07:41:02 amWell, for my tests it cannot make a difference, since I didn’t trigger on a random edge of the clock or data, but on the falling edge of the slave select signal, which is always related to the start of a packet. Consequently, data after the trigger point have always been correct (apart from the extra 0x00 decoding between packets) and I did not complain about invalid data before the trigger point other than that it wasn’t marked invalid in some way (no error bit indication as e.g. the SPI decoder on my LA does).QuoteYou’re right of course. Four lines is just the default setting, but I can wind it down to one if required. Tanks for the hint - I’ve corrected that statement in my review post.

author: Performa01
author_rank: Super Contributor
timestamp: January 04, 2016, 02:09:43 pm
content: MSO – Digital ChannelsThis is a short review of the digital channels that make for the SDS2000 MSO functionality, and there are two bugs right from the start:1. After enabling ‘Digital’, all digital channels appear at the same vertical screen position (as already shown in an earlier post). Only pushing the ‘Position’ knob in the vertical section where also the ‘Digital’ button sits, automatically aligns them in a way we’d expect it to be right from the beginning.2. The ‘Variable’ control in the vertical section where also the ‘Digital’ button sits can be used to select a specific digital channel, which is then highlighted in red. Turning this control should select the digital channels in a consistent order 0~7, but by en-/disabling individual channels in the soft menu we easily get into a state where channel selection has discontinuities or even goes all over the place, which is rather confusing.The bugs mentioned above are still relatively easy to handle, so we can continue the test with some real signal.It should be noted that with digital channel enabled, memory is generally restricted to 14Mpts maximum for both analogue and digital, except for 1ms/div timebase with only one analogue channel per group enabled, where we can get a combination 28Mpts for analogue and 7Mpts for digital. Maximum sample rate for digital channels is generally limited to 500MSa/s.The signal is a 7 bit counter changing state every 200ns and stopping for about 1µs at every 19th edge, thus creating some interesting stream of bursts.On top of that, the MSB (D7) is fed with an asynchronous pulse <10ns wide at a repetition rate of slightly more than 1µs.The basic settings for my tests are maximum memory, peak detect acquisition, x interpolation, vector display.Analogue channel 4 is hooked up to the LSB of the basic counter in parallel with the digital channel D0, in order to see the time skew between analogue and digital channels – but we have to expect some inaccuracies here due to the different signal path through the analogue probe and the additional capacitive load.Trigger is set to the falling edge of the analogue signal on Ch. 4.Digital bus decoding has been set to display all 8 bits at once, which should give some interesting pattern, when the short, asynchronous pulse on D7 appears at random positions.A detailed view of the signals can be seen in the following screenshot (Digital_Signals_200ns)As can be seen, everything looks fine so far. Digital channels appear blue when low or falling edge and green when high or rising edge, which I think is a great idea. The digital channel currently selected by the ‘Variable’ control next to the ‘digital’ button is displayed in red and I haven’t found a way to disable that, but then again it’s also nice to have one particular channel stick out.The bus decoding on the bottom of the screen shows the correct results and at this timebase setting, space is way too narrow to display any values when the short pulses occur, as has been expected.I should also mention that despite the bus decoding, screen update is as quick as it can get and measured waveform update rate is about 2500/s in this scenario.The next screenshot shows a detailed view of the trigger point at a timebase setting of 5ns/div (Digital_Signals_5ns_Probe_D0)As can be seen, there is a delay of precisely 6ns from digital channel D0 to analogue channel 4, so the digital channels have less trigger delay. But when talking about delay times of a few nanoseconds, it’s quite obvious that the digital and analogue probes cannot be exactly the same and I will repeat this test with a direct coaxial connection to the analogue channel in a subsequent post.We also see a slight uncertainity at capturing the digital channels, as the transition of D3 occurs 2ns later compared to D0 and D1. Interestingly, we still get a valid bus decoding (0C) for that misaligned portion of the signal at the bottom of the screen.In general, we cannot expect a timing accuracy of better than +/- 2ns at a digital sample rate of 500MSa/s.Now let’s have a look at a huge amount of data. At a timebase of 2ms/div, digital and analogue channels both run at 500MSa/s with 14Mpts of memory and the picture we get is a little boring (Digital_Signals_2ms)If we zoom in 1000x by lowering the timebase to 2µs/div (in stope mode), we get a good overview of what’s actually going on here (Digital_Signals_2ms_2us)Bug:The bus decoding at the bottom of the screen is a fair bit misaligned though. The displayed values should be aligned with the gaps in the D0 burst signal, but the first one (7d) is already about 1µs late, and it gets progressively worse and ends up with a lag of some 3µs for the last value (49).If we zoom in even further, 10000x at a timebase of 200ns/div, bus decoding gets well aligned again (Digital_Signals_2ms_200ns)With a zoom factor of 200000 at 10ns/div, we find a serious mismatch between analogue and digital channels (Digital_Signals_2ms_10ns_Probe_D0)Now D0 is about 44ns late with regard to Ch. 4, which doesn’t appear too bad at first, considering the huge zoom factor, but then again I still wouldn’t expect more than 10ns, as we saw a skew of 6ns earlier, where Ch. 4 was sampled at 2GSa/s and it now is at 500MSa/s, which might introduce another 2ns of uncertainty. Even more surprising, the skew has changed sign, i.e. the digital channels now lag the analogue one.Finally let’s have a look at Zoom mode (Digital_Signals_2ms_Zoom_200ns_D40us)While it certainly works for the signal traces, it does not for the digital bus decoding, which shows just nonsense.Bug alert!ConclusionDigital channels are basically working just fine, apart from the two bugs regarding initial channel position and slightly random channel selection mentioned at the start of this review.Digital bus decoding is fine in many regards, especially its response to narrow pulses, but still has some alignment issues as shown in this review. A big issue is the zoom mode, where it’s just displaying nonsense.The correlation between digital and analogue seems fine too, except when zooming into a long waveform, where the error can get surprisingly high at up to 50ns (from +6 to -44ns).

author: Performa01
author_rank: Super Contributor
timestamp: January 04, 2016, 02:28:13 pm
content: MSO – Digital Channels Pattern TriggerNow that we’ve seen digital channels basically working, we would like to know if we can trigger on a digital word by means of the pattern trigger. In particular, I wanted to know if the trigger reliably captures narrow pulses on the digital channels.The setup is pretty much the same as in my previous post, but as triggering on narrow pulses is a major topic here, we want to examine these pulses a little closer and also repeat the channel skew test without the analogue probe.I’ve now connected Ch. 4 to the pulse generator directly via a coaxial cable and activated the 50 ohms termination on the scope input. I’ve used a BNC T-adapter at the generator output to tap off another signal for the logic probe and fed it there over a coaxial cable of equal length. Of course this arrangement introduces a considerable mismatch and we will see a 2nd (reflected) pulse about 10ns after the initial one, which is double the time the pulse travels through 1 metre of coaxial cable with a velocity factor of about 0.66 (1m forward, then 1m return) and is because the end of the cable connected to the digital probe isn’t properly terminated. This reflected pulse is about 30% the amplitude of the initial one, so the return loss is still high enough to make reasonable measurements.First we look at the pulse delay from digital to analogue (Digital_Trigger_Delay)As can be seen, the analogue channel is still late, but it’s only by 1~4 nanoseconds, which is within the range of expectations for a 500MSa/s LA and a casual setup like this. In particular, it should be way accurate enough for practical tasks, where we have to correlate analogue with digital signals.This picture also shows the pulse width to be slightly under 4ns at the threshold level of 2.5V that I’ve set for the digital channels as well as for the analogue trigger.Now for the actual triggering. The pattern trigger setup includes analogue and digital channels at the same time, which is exactly what we want. For this test, I leave the analogue channels alone and just use the simplest possible digital trigger word for a start (Digital_Trigger_Setup)The trigger condition is very nicely displayed on the right info bar with don’t cares for all channels except D7, which is set to high.It can be seen that the trigger shows some unexpected 20ns lag, but other than that it works reliably.Now let’s try a full qualified trigger word HHHHHHLL and see what we get (Digital_Trigger_11111100_50ns)Well, the result is similar to before, but now the trigger only fires when D0 and D1 are low and all others, including D7, which is connected to the narrow pulse, are high. The 20ns lag is still there.Now let’s try that with a huge amount of data again at 2ms/div (Digital_Trigger_11111100_2ms)As there is nothing much to see, we immediately zoom into the waveform 2000 times by lowering the timebase to 1µs/div (Digital_Trigger_11111100_2ms_1us)At this timebase setting, triggering appears to be a bit early, but still accurate enough. The bus decoding only works occasionally and appears a bit misaligned, just as we’ve seen it before.If we zoom in even further at 200ns/div, we can see the trigger is indeed almost 30ns early for a change. So there generally seems to be a uncertainty of that magnitude, which I don’t have an explanation for. At least the trigger condition is met correctly (Digital_Trigger_11111100_2ms_200ns)ConclusionTriggering on the digital channels works almost as expected, but I cannot think of any real reason why there has to be that rather high uncertainty of at least +/- 30ns, that I’ve observed in the test.

author: Mark_O
author_rank: Frequent Contributor
timestamp: January 04, 2016, 06:53:18 pm
content: Quote from: Performa01 on January 04, 2016, 02:09:43 pmNicely done coverage of the MSO section.QuoteOne thing that may help there is if the analog channel menu has a Deskew Setting on Page 2 (as the 1000X does). That could be used to bring the analog and digital channels back into alignment (at least initially). Though it would do nothing to rectify the 50 ns shift in that relationship which you observed later.One thing to keep in mind is that as clean and well-defined as the digital traceslook, they are still based on a user-set threshold-level. And that threshold is adjustable. While your digital generator is "fast enough" in the context it's being used, your scope traces indicated an ~18ns fall-time (and presumably similar rise-times). That throws a fair amount of uncertainty into the process, which significantly exceeds the 2ns you (correctly) attributed to sampling resolution.In addition to that, the digital channels will have a certain amount of hysteresis built-in (if they're any good), which will contribute to the uncertainty. On a rising-edge the digital state will be delayed, as will the state-transition on a falling edge. They generally balance out fairly well (assuming similar rise & fall rates), so the pulse-width itself isn't impacted too badly, but the pulse position will definitely be affected.NB: But just by adjusting your digital threshold level, you should be able to watch the skew between the A and D channels shift.

author: Performa01
author_rank: Super Contributor
timestamp: January 04, 2016, 07:04:00 pm
content: Trigger puzzleIn preparation of another test I stumbled across some funny phenomenon with the trigger system.Have a look at the screenshot (Trigger_Puzzle_10ns)Yeah, nothing special – just a pair of narrow pulses spaced some 10ns apart – and the SDS2000 shows a rock stable triggering here, no worries whatsoever. I use rising edge trigger without any specialities and the trigger level is somewhere near half the signal amplitude, but that doesn’t matter anyway. The curious thing is that the scope reliably triggers on the 2nd pulse, whereas I’d have thought there should be a bigger chance to trigger on the first one.Why is it so?Just out of curiosity I adjusted the pulse spacing and at 24ns I finally got this (Trigger_Puzzle_24ns)Now we got like a 50% chance to trigger on the first pulse. Still not quite what I’d expected, yet a fair bit closer. And in this case, no amount of trigger holdoff would change the picture either, which is also rather surprising.Pulse and Interval triggers didn’t work either.With the minimum holdoff time of 100ns, I had to increase the pulse spacing to 30ns, in order to get a stable triggering again (Trigger_Puzzle_30ns_H100ns)Without holdoff, the occasional triggering on the 2nd pulse can still be seen as a faint image (Trigger_Puzzle_30ns_HC)So I’ve finally found a case, where the scope proved unable to trigger on a signal.To sum it up:With a pulse spacing > 30ns we can get stable triggering by means of the trigger holdoff.With a pulse spacing 19 ~ 29ns we can’t get a stable triggering.With a pulse spacing < 19ns we get stable triggering on the 2nd pulse unexpectedly.Granted, that’s no big deal, it is just the very special case of a pair of narrow pulses that have a spacing in the range of 20.to 30ns (triggering on the 2nd pulse for a spacing below 20ns is certainly acceptable).

author: Performa01
author_rank: Super Contributor
timestamp: January 04, 2016, 07:37:09 pm
content: Quote from: Mark_O on January 04, 2016, 06:53:18 pmI’ve already demonstrated the deskew option to work fine in one of my earlier posts in this thread, and yes, I’ve actually tried it in this situation as well – and it worked a treat.I still didn’t mention it in my review, as I thought it was ridiculous to try to compensate for a few nanoseconds, when we already have a sampling uncertainty of 2ns for digital and at least 500ps for analogue.QuoteLook closer. The automatic measurement of the fall time is not valid in the screenshot you’re regarding to, as it takes some 10ns for the last 20% of signal amplitude to actually reach the ground level. Actually, it takes less than 5ns to approach the 2.38V trigger level. In later screenshots you can see even the automatic measurements indicating rise and fall times between 8 and 10ns.QuoteThat's certainly true and also the reason why I didn't look further into it when I observed a channel skew of just about 2ns in my digital trigger test. By this result I was convinced that initial matching between channels on the time axis is not an issueQuoteThat’s the reason why I explicitly set the digital trigger level to 2.5V and yes, I failed to make the analogue trigger level exactly the same for the first test, but 2.36V should still be close enough, especially considering that the analogue and digital triggers would most likely be very different in their nature.We know that the analogue trigger is digital, based on the sampled data. This cannot be the case for the digital channels, as there is just one bit per channel, so it has to be analogue…

author: Performa01
author_rank: Super Contributor
timestamp: January 04, 2016, 08:30:36 pm
content: Sequence ModeThere is one item under the Acquisition menu still unexplored – the sequence mode, which is supposed to give us an immense boost in waveform update rate. Well, let’s try that.I’ve set up a double pulse that’s repeated every 100ns (Sequence_Signal_Overview)The scope was set to peak detect mode with x interpolation, dots display and 14Mpts of memory, as this should be sufficient for up to 100000 segments of 140 point each..Then I tried to set the number of segments, but gave up after several minutes with hurting fingers at 50001. This is another instance, where the ‘Adjust’ knob is just useless – nobody has the time or patience to sit there for minutes in order to wind up some value – or maybe we should use our Proxxons or Dremels in order to spin that knob? Okay, later on I discovered that I just needed to turn the knob counter-clock-wise a tiny bit in order to get to the maximum value of 80000, but what if you really want 40000 for some reason. Anyway, my test was done with 50001, for I was only able to dial in odd numbers for some oddreason (Sequence_Menu)I had to figure aut how the sequence mode is intended to work. First I just hit the ‘Acq. Mode On’ button and watched the screen, where we can see a counter reporting how many segments have been captured (that doesn’t make it on the screenshot for some reason). In my scenario, the entire process is lightning fast and the 50k segments are captured several times per second.I eventually hit the Run/Stop button and examined the history menu, but found just a couple thousand entries there. Of course not – it is all about filling the buffer at max. speed, and once it is filled, rearm and start over again – it is not a ring buffer. So I changed over to single shot trigger mode and sure enough, that finally worked. Hitting the ‘Single’ button once starts the sequence and fills the buffer, then there is a short break where some post-processing is going on and after that the scope goes into stop automatically. Now we can examine the history.There we have the first 7 captures in in the history list (Sequence_List_1)And here’s the last 7 entries, ending with 50001 (Sequence_List_50001)Looking at the timestamps, it took 172434µs to capture 50001 waveforms; that is 3.4486µs per waveform or 290k waveforms per second – more than twice as fast as the maximum waveform update rate in normal operation. Not bad at all.Now things certainly slow down a bit when we use vector mode and some might not like the appearance of just dots on the screen when there are just a few samples available. But that’s not an issue, as we can change the display mode to vectors after the capture if we really want to (Sequence_Display_Vectors)ConclusionSequence mode is a nice feature – pretty much a single shot capture of many trigger events at the highest possible waveform capture rate. Of course we will still miss lots of trigger events, just as in my scenario at least 10 million waveforms per second would be required in order to capture everything. Nevertheless a nice complement to the history mode!

author: Performa01
author_rank: Super Contributor
timestamp: January 05, 2016, 05:33:12 am
content: Channel Skew and the Impact of analogue probesBy reviewing the digital channels, I attached great importance to the time skew between analogue and digital channels and repeated the test without the analogue probe in my digital trigger review, where I finally ended up with a skew just over 2ns. The effect must have something to do with the internal signal processing in the scope, as the digital channels were always faster in these tests. Even in the digital trigger test, the transition on the digital channel can be seen at a point, where on the analogue channel the signal has not even begun to change its state.It seems clear to me, that all channels will be deliberately delayed quite a bit within the scope and the firmware just tries to balance those delays in a way that all channels are reasonably in sync on the time axis. This is the only way to get digital and analogue channels in sync, and without it, the ‘Deskew’ option for individual analogue channels would not be possible – and this has an adjustment range of +/- 100ns!After drawing that conclusion, there’s still one question left.What impact does the analogue probe have on a fast signal?To answer that question, I’ve set up a little test with a BNC-T-adapter directly at the generator output, that connects Ch. 4 directly via 1m RG58 coaxial cable whereas Ch. 2 is hooked up using the analogue probe and the BNC probe tip adapter (Probe_Impact_2ns)We see three versions of the same narrow pulse in this screenshot.The blue reference waveform is the undistorted original pulse with the analogue probe not connected.The green Ch. 4 trace shows the same pulse with the analogue probe connected. We see that the rising edge gets a bit slower and the peak amplitude is slightly decreased, as well as a bit more pronounced ground level disturbance right after the pulse. All these effects come from the additional capacitive load introduced by the probe.The magenta Ch. 2 trace shows the same pulse as it is seen by the analogue probe, and the difference is quite obvious now. In particular, we have a lag of 640ps, a more flat top with reduced amplitude and way more disturbances after the pulse.The same situation again, but without reference waveform and cursors and at a slower timebase of 5ns/div in order to show the differences and particularly the disturbances more clearly (Probe_Impact_5ns)This little experiment shows (at least) two things.1. The probe introduces about 640ps time delay compared to a straight coaxial connection. This is insignificant on a 300MHz scope.2. Nothing beats a properly terminated coaxial line. There are very little disturbances after the pulse compared to the signal delivered from the oscilloscope probe.

author: rf-loop
author_rank: Super Contributor
timestamp: January 05, 2016, 09:15:54 am
content: About Sequence mode speed.It is bit complex to show every things about its speed.Bit about memory. Example: 500ns/div and 1 channel used.Segment lenght is 14000 points. Inside one Sequence max count of segments is 6468. It use 90552000 points of memory.When user want use this Sequence mode it need know how equipment works and how to do optimal settings for different aplications.DSegment maximum speed is only one thing what is not meninful in many applications, say example quite low repeating radar pulses.One use for Sequence mode is case where is qquite slow repeating fast pulses and we are not interested of mean time. If example have 50ns pulses repeating 100ms period and we want inspect these pulse shapes.With 80000 segments we can capture 80000 pulses ans this recording take 8000 seconds. If take continuous record with big memory it need 16Tera points memory. Ok, Sequence mode we have only small slices of time... true, but scope is also wakeup in mean times and if there happend trigger events (example extra pulses/glitches what trig we can also get these! if they happend after trigger recovery time what is down to 2us)Some day I hope I can finish better table but before this work I will wait least next or second FW upgrade so that things are more mature.

author: Mark_O
author_rank: Frequent Contributor
timestamp: January 05, 2016, 12:35:15 pm
content: Quote from: Performa01 on January 04, 2016, 07:37:09 pmMy apologies for missing that. I have read all your findings, but I found them late, and tried absorbing them all over the last week. Obviously, I went too fast on some.QuoteIt was 6 ns, and I didn't feel it was ridiculous to try to compensate for that. But it's OK if you did.QuoteOK. You are correct, that I did need to look closer. Thanks.QuoteThat sounds a bit ironic. Analog channels having digital triggers. And digital channels having analog triggers.

author: Performa01
author_rank: Super Contributor
timestamp: January 05, 2016, 02:41:08 pm
content: Sequence Mode Speed reviewedWhen looking at the table published by rf-loop, the maximum waveform update rate for 5ns/div timebase (140 points/segment) ahould be 440k, whereas I’ve never seen more than 290k in my tests, so I thought I’d take a closer look at that discrepancy.First I want to share some general thoughts about sequence mode. It should be obvious that this mode is meant for situations where we have periodic events with considerable idle states (that are of no interest) between them. Segmented memory (or Sequence Mode, as it is called here) is the ideal tool if we want to capture as many events as possible without wasting precious memory by recording the idle phases as well.This is also the reason why I’ve set up my previous test the way I did:I created some interesting signal event – the double pulse – at a repetition rate of 10MHz, i.e. the event repeats every 100ns. This is about the limit where sequence mode in general starts to make sense, because at 5ns/div, one segment already covers a time span of 70ns.At a sample rate of 2GSa/s and with 70Mpts of memory, we could cover a total time span of 35ms, so we could capture a total of 350k events with one traditional single shot recording.With segmented memory and 70ns = 140 points per segment, it could be 500k events, which is only slightly more.So while my test setup would generally be the limit case where segmented memory starts to give some benefit, this is not true for the SDS2000, as it is limited to 80000 segments maximum. But of course that doesn’t make the test pointless, as it could still show how sequence mode works and what kind of speed is to be expected. And of course one of the motivations to use 5ns/div was that the SDS2000 shows the highest waveform update rate at this timebase in normal operation.Even though my test wasn’t meant to show the absolute maximum speed that could be achieved, it is still puzzling why it only yielded 290k as opposed to the 440k that rf-loop has measured.The obvious difference is the signal frequency – 50MHz sine as opposed to 10MHz double pulse. Of course signal frequency has an impact. In a worst case scenario, the freshly re-armed trigger just misses an edge and has to wait for the next one, and this lost time gets shorter with higher signal frequencies.On the other hand, a 50MHz sine isn’t a realistic test scenario, as no one would use segmented memory for a signal like this. 10MHz should be fast enough and it really shouldn’t make any noticeable difference as long as we’re talking about waveform update rates well below 1000k. Yet I had to try and use a 50MHz sine in order to see what I get. Guess what – it was exactly 290k again. So the signal frequency was not the critical parameter here, just as predicted.What else could it be?There’s nothing left but trying all possible combinations of acquisition and display parameters in order to see what makes the difference. I did not try different trigger modes, just DC-coupled edge triggering without any specialities. I also kept using the 50MHz sinewave as the signal source. Other common settings are single channel (4), fast acquisition and 80k segments.I never managed to get more than 292709 waveforms per second at 5ns/div timebase. As was to be expected, display type (dots/vectors) and acquisition (normal/peak detect) didn’t make the slightest difference, but sin(x)/x reconstruction does, reducing the update rate to just 129k.So I didn’t get there. Would the initial selected memory depth make any difference? That would be simply a bug, as the actual amount of memory used doesn’t change as long as there is enough available to fit the specified number of segments. So I tried different memory settings also, but as expected, it didn’t change anything.Finally I tried the fastest setting, according to rf-loop’s table, i.e. 50ns/div. It was indeed a little faster, about 315800 waveforms per second, but nowhere near the claim of 500k.So what the heck is going on?Finally, in a desperate attempt to solve this puzzle, I changed the input channel from 4 to 1.And what do you know – at 5ns/div. I got a waveform update rate of 444483.95 frames per second!Big Question:Why is channel 4 so much slower than channel 1?I have tested all four channels and sure enough, channels 1 and 2 show the speed as indicated by rf-loop. Channels 3 and 4 are significantly slower.I couldn’t be bothered to check any other timebase settings, as I’m pretty confident that rf-loop’s table will be valid for channels 1 and two, whereas channels 3 and 4 will be about 2/3 of that speed – at faster timebases at least, maybe they catch up at the slower ones.See attached table for the complete results (Sequence_Mode)EDIT: Replaced the table with correct size

author: Performa01
author_rank: Super Contributor
timestamp: January 05, 2016, 03:14:51 pm
content: Quote from: Mark_O on January 05, 2016, 12:35:15 pmSorry, my response on this was sloppy and 6ns would indeed justify the use of the deskew option in certain situations.The true reason why I didn’t mention it in my review was because I thought it’s just too obvious and goes without saying that one could use the deskew to align the channels, and the fact that the sample uncertainty adds some jitter that makes it pointless to try to compensate for better than +/- 2ns.QuoteWhat I forgot to mention was that if you look close, you can see that the digital edge is at a time where the analogue channel has not even started slewing, so apart from the fact that the transition times aren’t as bad as 18ns, the traces on the screen clearly indicate that they cannot play a role for the amount of lag observed.QuoteWell, that’s what I thought too when I wrote thisBut then again, nothing wrong with an analogue trigger when we expect fairly fast transitions. Every single logic gate has an analogue (sometimes Schmitt) trigger built in after all

author: rf-loop
author_rank: Super Contributor
timestamp: January 05, 2016, 03:15:43 pm
content: Quote from: Performa01 on January 05, 2016, 02:41:08 pmYes, this is also what I think but for finding maximum speed I have used this signal. (also searched wide span of frequencies and there is big freq band where I can get same result, not only 50MHz what is some kind of middleway compromise)Why it is also important that segmented memory acquisition is fast. As you tell mostly this function is used for - just as you tell. But still it is important it can capture fast agen if there happend some spike or extra pulse, high glitch etc. This is why also Hewlett-Packard (so sorry it is today Keyshit after Fiona catastrophe when it was destroyed to Agilent) argument for segmented memory speed (trigger recovery time).In different aplications user need find optimal settings for just this individual case and for this, there ismportant thing: "Know your equipment".----This whole case need bit more inspections because in FW there is something wrong and/or not optimal.Example why heck Sinc is mixed there in sequence mode for timebases 1ns/div to 20ns/div. Segmented memory cquistion do not need anything but push as fast as possible raw ADC data to memory and nothing - nothing else. When scope is stopped for analyzing captured segments there user can use Sinc and/or vectors or what ever he want. (and tools for inspect these segments need develop better. There is not even possible stack segments over segments in playback (or select buffer how many is stacked (overlayed) for better finding anomalies, no persistence available, etc. But first acquisition need work without any problems and - please Siglent - do something for this multifunction knob useability/ergonomy)There is also some other mystery with wfm/s speed (time ago I have also informed Siglent about some problem with scope wfm speed in some "semirandom" cases). Some times it go only bit over 70kwfm/s and then suddenly after some playing with knobs/buttons and then it reach full 140kwfm/s. I have not find "logick" how this happend. And do this have also something to do with second channel group (CH3 and CH4) speed. Next I will check what maximum I can find with CH4 (or 3). Limiting factor is some lack of time for this...Add:---------QuoteI can confirm this. (Measured) If CH3 or CH4 alone on, just this.If both, CH3 and 4 are open, just around 10kwfm/s more.But after then I find also more interesting things related to CH on off combination and also together with t/div settings that this need check better. Question is how much is wise to do investigations if next FW agen change things (and hope remove difference between channel groups)Also there is intersting finding for rare glitch hunting if think average wfm/s speed.But here two of these intersting findings (but only for 1GSa/s speed)1. I find in Sequence mode setting what give max segment speed around 545ksegment/s(measured with second scope and calculated also from history timestamps.2. Case where CH1 and CH2 are both on and Sinc off and display dots etc. timebase 10ns/div and Sequence mode. Sequence repeating interval is more short what I have find before.Add agen:There is one open question.Example. Sequence mode. If example in one sequence is 80000 segments. After these are acquired then acquisition of course stop and scope start do many things including display update for show waveform before it start new sequence. Question is, how many segments it display overlayed on the display before it start new sequence. It is least some hundreds in this case but how much really? I do not believe it stack all segments. If I change amount of segments from 1 to hundreds it clearly give more and more intensity grading when I rise number of segments.I found it intersting because with some settings and Sequence mode in use it can capture over 300ksegment/s continuously (10s average). Checked using second scope for analyzing trig out signal and also using simple trig out signal pulse counting. For this I use HP53131 counter in pulse count mode with 10s gate time. Second oscilloscope triggercounter and HP give same result, over 300kwfm/s. In this case inside one sequence segment speed is 545ksegment/s. This amazing speed is reached using CH1 + CH2 on, 10ns/div (segment lenght is 140pts and sampling rate 1GSa/s) , 50MHz signal in and Sinc off, display dots. Of course display update speed is not high but intersting is how many segments are stacked for display in every turn.

author: Performa01
author_rank: Super Contributor
timestamp: January 05, 2016, 09:30:24 pm
content: @rf-loopRegarding the number of segments used for a single display update I’ve tried a little experiment.Display dots, peak detect, 70Mpts, fast acquisition, x interpolation.Sequence mode, 5ns/div == 140 points.Used my darling channel 4 again (even though it's slow), sorryI fed the scope with a 50MHz sinewave, 100% amplitude modulated with a 10kHz sawtooth and tried to count the individual traces on the screen, but it were still too many (Sequence_RT_50MHz_Mod_10kHz)In a 2nd attempt I increased modulation frequency to 40kHz (Sequence_RT_50MHz_Mod_40kHz)We can clearly see 7 individual traces, with nice and evenly spaced amplitudes due to the ramp modulation.Without sequence mode, we get a little more under otherwise same conditions (Standard_50MHz_Mod_40kHz)The full range of amplitudes is run through 40000 times per second and we can see 7 traces. And despite dots display, all 7 traces don’t show any gaps.At 10kHz modulation frequency we can assume it would be four times as much traces, hence 28 – and we still don’t see any noticeable gaps.So this won’t get us very far. But what if we just reduce the modulation frequency to the point were we don’t get a nicely filled sinewave anymore, but observe some discontinuity instead?Down to 300Hz everything looked just fine. At 200Hz the picture suddenly changed (Sequence_RT_50MHz_Mod_200Hz)First we need to remember that we need about 300ms to fill the memory with 80000 segments (for Ch. 4 that is). So even a low modulation frequency of just 300Hz yields about 100 full modulation periods in memory. And this is about the lowest frequency that gives a correct modulation display without vertical gaps.In normal mode, we don’t get any gaps even with just 100Hz of modulation frequency.So while this doesn’t answer your question as how many waveforms make it to the screen, it is certainly a proof that not all waveforms are displayed, hence sequence mode cannot serve as a secret trick to have a very high waveform update rate that would not miss anything despite the slow screen update of just about 3 per second…

author: Mark_O
author_rank: Frequent Contributor
timestamp: January 06, 2016, 06:57:04 am
content: Quote from: rf-loop on January 05, 2016, 03:15:43 pmSo let me check that I'm following correctly. At 545k segs/s, that means 1.83 us/segment. Since each triggered acquisition runs for 140 ns, it doesn't trip again for 1.69 us afterwards. That's the inter-segment dead-time, where the trigger hasn't been rearmed yet. Even though your 50 MHz signal is providing another trigger event every 20 ns.Then at the end of the segment burst, there is a second time gap, where it sets up to grab the next burst (clear and reset). With 330k segs/sec, that means the average time between segments has increased to 3.03 us, from the 1.83 us, or a 1.2 us delta/seg. Since each burst here is 80k segments, that means the inter-burst gap is 9.6 ms.Of course, as Performa01 said, we don't use Sequence Mode to look at rapidly repeating,continuoussignals like this in real life. However, tests such as these are useful in determining the capabilities of the test instrument. The most interesting from my perspective being the dead-time that occurs between segments, while the unit re-arms to catch the next trigger. Which has been demonstrated here to be ~1.7 us. Which isn't bad performance at all.If the events you're trying to capture are always spaced further apart than that, even if they only occur maybe once per millisecond, or even once per second, then ALL of them will be captured if no two are closer together than 1.7 us. That's good to know. Plus a big win for Sequence Mode. And conversely, if not, then they all won't, and some will be missed.

author: rf-loop
author_rank: Super Contributor
timestamp: January 06, 2016, 11:34:47 am
content: Perhaps this explain better what is going on.(it need of course also note that dead time inside sequence burst phase between segments is much higher what is example with 50ns/div where segment lenght is 700ns or 1400ns depending samplerate. If look maximum 500ksegm/s speed previously measured using CH1 and 50ns/div. There is (quite exactly) 2000ns interval in burst phase. There segment time is 700ns and between segments dead time 1300ns.)But here this case where long time average go over 300ksegment/s speed and speed during Sequence mode segment acquisition burst over 540ksegment/s. (here 80000 segments, CH1+CH2 open, 10ns/div)Images tell more.Snap shot during Sequence acquisition, running continuously over and over (not one shot at this time).Just at snap shot random time there was going segment number 48659 and display waveform is from previous Sequence. (Settings: Sinc OFF, Display Dots, Trig normal, rising edge, Holdoff closed)Here second scope (SDS1202X) CH1 is connected to scope under test (SDS2304) Trigger Out signal.There can see Sequence segment acquisition burst and then scope busy time when it processes all nessessary things before it start next period (visible in top window right side). SDS1202X trigger event based counter show around 310kHz frequency. (I do not know how this counter exactly work but freq display is jumping around between 300 and 325kHz but mostly near 310kHz. Because this, I also check it using HP 53131 for counting pulses over 10s gate time (not as frequency calculating mode but just as simple pulse counter, what is better mode for this case. Result certify this result in image if we tell average speed is ~310ksegment/s.Whole period time here is 258ms. 80000 segments acquisition burst time is 141.5ms and oscilloscope busy time is 111.5ms. This busy time is valid only for this instance.And here scope stopped for looking captured seqments. Segment number 1. Also to image cloned segment number 80000 timestamp.Still even with long busy time between Sequence periods it give over 300ksegment/s average speed and here inside segment acquisition phase (80000 segment burst) speed is ~545ksegment/s.I believe here is reached some of this SDS2000 series some upper possible limit values.(with current FW)Quote

author: Performa01
author_rank: Super Contributor
timestamp: January 07, 2016, 04:32:24 pm
content: Quote from: rf-loop on January 05, 2016, 03:15:43 pmWell, I might have an explanation for that. While vectors and dots really is just a matter of screen representation, sin(x)/x is an actual signal processing step required to recover the original signal. This in turn is required by the digital trigger system in order to determine the exact trigger point on the time axis.If this option is set to just ‘x’, the scope will just use a linear interpolation and introduce some noticeable jitter by that. I’ve demonstrated some of the odd effects on a fast sinewave in absence of sin(x)/x reconstraction in an earlier post, where we could consider the width of the trace area for any given (trigger) level would be the amount of jitter (Trace_Peak_x_Fast_Vectors)QuoteI might have finally found a way to estimate this. After several experiments I believe that the scope just displays any (the first - or last – or whatever?) 750 +/-50 waveforms for every filled buffer.I got these results rather consistently for 80000 segments at timebases from 1 to 10ns/div (used Ch. 4 again, but that probably doesn’t matter in this case). Not tested anything else yet.

author: rf-loop
author_rank: Super Contributor
timestamp: January 08, 2016, 05:26:13 pm
content: Quote from: Performa01 on January 07, 2016, 04:32:24 pm

author: Performa01
author_rank: Super Contributor
timestamp: January 09, 2016, 12:00:44 am
content: Quote from: rf-loop on January 08, 2016, 05:26:13 pmYou are certainly right for lower frequencies, up to about 100MHz at 1GSa/s.If you look at my picture (Trace_Peak_x_Fast_Vectors) again, then at 300MHz @ 1GSa/s there is also a fair amount of uncertainty regarding the pk-pk amplitude. While triggering would still work as you described at a trigger level of 0V, we certainly would miss trigger events if the trigger level is set to >60% of the peak amplitude.The same situation as for the picture in my last post, but this time with trigger level set to 66% of the signal peak amplitude (Trig_Peak_x_Fast_66%)Doesn’t look like a stable and reliable triggering anymore, does it?For a periodic signal, this wouldn’t be a big deal, as every missed trigger condition just means 33ns wasted time. So even if we frequently miss 10 in a row (which is rather unlikely), it would only decrease waveform update rate by some 10%.But what about sporadic events, like the glitches you mentioned and that are the reason why a high segmented memory trigger rate is so important according to HPeysightilent?If we have the odd narrow pulse that has been acquired by less than 4 samples, its amplitude will most likely be too low without sin(x)/x reconstruction – except when we are lucky and a sample just hits the peak, but there is only so much chance that would happen.The essence of what I’m saying is, that a trigger condition that we’ve missed because of the lack of proper signal reconstruction, cannot be ‘repaired’ or ‘fine-adjusted’ afterwards, simply because recording has never even stopped (and post processing started) due to a trigger condition.But then again, up to some 100MHz we’re good without sin(x)/x.Below there is a borderline case with a 4ns wide pulse, which corresponds to a fundamental frequency of 125MHz. Without reconstruction it looks like this (Pulse_4ns_Peak_x_Fast)There is a fair bit of uncertainty visible, but the scope still wouldn’t miss any trigger events as long as the trigger level is kept below some 93% of the peak amplitude.With reconstruction filter active, everything is fine. Also the automatic measurements for the transition times get instantly more accurate (Pulse_4ns_Peak_sinx_Fast)QuoteMy test results are in fact even more consistent than what I wrote, according to the following table:1ns/div 7322ns/div 7845ns/div 77110ns/div 796My test was simple: I used the setup as described in an earlier post and tweaked the modulation frequency until I just got one full modulation period, i.e. no gaps on the screen.Since the peak amplitude of my signal was less than 3 divisions, the ADC would resolve this in only less than 70 different levels, which gives an uncertainty of nearly 1.5% already. Then add the difficulty to recognize just one single missing value, i.e. 1/25 of a division, all the more so since there is also a bit of noise, obscuring tiny gaps, the total uncertainty is considerably higher, but obviously still better than 5%, according to my results, that could also be expressed as 763 +/- 4.33%.I didn’t look any further into this though, as it already has become clear that it wouldn’t be the secret weapon for glitch hunting. Without this prospect, it just doesn’t matter, how the signal actually is displayed in sequence mode.If, on the other hand, we would have actually found that we could get a complete signal representation on the screen at a higher waveform capture rate than in normal mode, then this would just have been a hint for a bug, because then sequence mode would have done exactly the same work as normal mode, just in bigger blocks, so to speak. So it really shouldn’t be faster in this case.

author: rf-loop
author_rank: Super Contributor
timestamp: January 09, 2016, 10:39:11 am
content: Do you believe primary trigger is generated after interpolation?I do not.But there is also signs about bug or even design error in trigger "box". (At this time this is just only suspect, not at all enough tested and this is so "deep inside engine" thing and because it can only test indirectly it is better to do with other peoples with some other test idea...for avoid faulty reasoning - fallacy.)It looks like (and this is NOT confimed, only light suspect until more real evidence) trigger is not generated from interleaved 2GSa/s data. More it looks like trigger look only one ADC data and so 1GSa/s. (or there is some other things wrong)This is old case but I have forget it totally. Long time ago I wonder why trigger counter drops out so easy where trigger level is not even near signal top. Image on TFT looks like all is ok and stabile trigger(of course it looks ok because scope is enough fast for eyes and there is enough well trigged waveforms and because captured waveform position adjustment works good),but counter start drop out specially if look with 2GSa/s and use lines and then Sinc on or off signal is far over trigger level.But, surprice. With same signal turn to 1GSa/s (take other channel on) and look now signal with lines and Sinc on or off. Surprice is that there is easy to see what is level where trigger counter start dropping out. Because worst case one signal cycle samples are just around trigger level.If it use 2GSa/s stream, worst case data points are still far over trigger level. So why counter start dropping. At this time I think it is "only" this counter... so not so much for it and I forget it from more testing.I think counter do not have other source but just this primary trigger signal. I do not believe there is arranged to some other things just for this counter so perhaps this can use here.It is more easy to test with over 300MHz sinewave. Around 375MHz is some kind of "sweet pot" for visual inspection so that this can see extremely clearly. (if then use measurements so that adjust input signal level so that with 2GSa/s scope show same p-p level what it show using 1GSa/s . In all cases of course 1ns/div.There can find, using 2GSa/s, trigger level where trigger counter just barely do not drop anything.Then turn to 1GSa/s and adjust input signal level for same averake p-p value. You find this point in trigger level is exactly same.Turn Sinc off. Look where is trigger level related to 1GSa/s worst case samples. Also this can nice inspect more if stop now scope and search wfm history slowly.Why it is same for 1 and 2GSa/s. Perhaps due to design error, bug in FW or this is only way for this speed?Why it is same for Sinc on or off is perhaps clear. There is not any Sinc interpolation before it generate primary trig from data stream.

author: Performa01
author_rank: Super Contributor
timestamp: January 09, 2016, 04:38:33 pm
content: Quote from: rf-loop on January 09, 2016, 10:39:11 amYes, I did believe that, simply because I could not think of any other way to get reliable triggering at high frequencies – and as we all know, I think the trigger system of the SDS2000 is hard to fault and certainly one of its strongest points, but…… after reading your reply and performing some more experiments, I stand corrected. Well, that’s the beauty of having discussions with other engineers, as this prevents us from flogging a dead horse…I can see why you call 375MHz a ‘sweet spot’There are numerous others, 388MHz for instance. Still I thought I’d stick with just 300MHz as I didn’t want to go far outside the bandwidth specification for this scope.I’ll show my experiments first and discuss it in more detail afterwards.Common settings are dot display, no sin(x)/x reconstruction and fast acquisition.First there is my test signal: a 300MHz (<50ppb), 500mVrms sinewave. At a trigger level near the centre, the trigger frequency counter of the SDS2000 shows the correct value at its usual poor accuracy and low resolution, i.e. an error of -20ppm. So the trigger frequency display of 299.994MHz shall be the reference for the following tests. Note that the sinewave looks reasonably undistorted in this screenshot, despite no sin(x)/x interpolation has been used (Trig_12mV_2GSa_300MHz_dots_fast_x)At a sample rate of 2GSa/s and a trigger level of 348mV, the distortion becomes much more evident. The frequency display still shows the reference value, but would start to drop if we set the trigger level any higher (Trig_348mV_2GSa_300MHz_dots_fast_x)By reducing the sample rate to 1GSa/s, the picture changes dramatically – doesn’t look like a sine at all, does it? What strikes me is the peaks at the trigger point and on top of the first and last negative halfwave – these look somewhat artificial. The trigger counter has now dropped from the reference value, and even though it might be less than expected, it still shows that there is a difference if the sample rate is cut in half (Trig_348mV_1GSa_300MHz_dots_fast_x)Now the same experiment at an even higher trigger level of 500mV. At 2GSa/s, the distortion is even worse now and peaks on top of the wave become visible even at that sample rate now. The trigger frequency counter has dropped dramatically to just 196.923MHz by now, indicating that more than 33% of the trigger events get lost (Trig_500mV_2GSa_300MHz_dots_fast_x)If we reduce the sample rate to 1GSa/s again, the pivture does not even show a waveform anymore. Instead, we get some funny curved lines plus even something that looks like a flat oval at the trigger point. Trigger frequency has dropped even further to 178.324MHz, once again the difference is less than expected, but there is a difference after all (Trig_500mV_1GSa_300MHz_dots_fast_x)Now what does that tell us?First I want to quote the datasheet, which says that glitch detection works down to 1ns. That indicates that there is always some monitoring going on, which has to be independent from the main acquisition sample rate. Remember how I demonstrated peak detect working even in roll mode at very low sample rates <1MSa/s, where the scope still didn’t miss a single 4ns wide pulse. This would not be possible at sample rates <250MSa/s, if the main acquisition system was the only mechanism in effect.So my current guess is that the ADC always runs at full speed and the current sample rate displayed on top of the info bar only determines the amount of data to be stored in sample memory. At this point, the decimation mechanism (normal or peak detect) has to sit – and also the primary trigger system.For me this would be a satisfactory estimation on how this scope works, if it weren’t for the surprisingly small difference between 1 and 2GSa/s.

author: nctnico
author_rank: Super Contributor
timestamp: January 09, 2016, 05:14:39 pm
content: Quote from: Performa01 on January 09, 2016, 04:38:33 pmThe trigger system in any DSO works by detecting whether a threshold has been crossed. The values of the samples where the threshold crossing occured are stored and used to calculate (interpolate) the exact trigger point and required shift to adjust the time reference of the samples so subsequent acquisitions overlap eachother perfectly and the signal is properly aligned with the trigger point.

author: tautech
author_rank: Super Contributor
timestamp: January 09, 2016, 07:28:51 pm
content: Quote from: Performa01 on January 09, 2016, 04:38:33 pmTypo?

author: Performa01
author_rank: Super Contributor
timestamp: January 09, 2016, 08:42:59 pm
content: Quote from: nctnico on January 09, 2016, 05:14:39 pmWhat you describe is the traditional analog trigger architecture.We are talking about the SDS2000, which incorporates a fully digital trigger system.

author: Performa01
author_rank: Super Contributor
timestamp: January 09, 2016, 08:45:04 pm
content: Quote from: tautech on January 09, 2016, 07:28:51 pmYesssCan you imagine what the 1GSa/s recording would have looked like at 500MHz?

author: tautech
author_rank: Super Contributor
timestamp: January 09, 2016, 08:52:02 pm
content: Quote from: Performa01 on January 09, 2016, 08:45:04 pmWill you examine the Power Analysis option?

author: nctnico
author_rank: Super Contributor
timestamp: January 09, 2016, 08:57:49 pm
content: Quote from: Performa01 on January 09, 2016, 08:42:59 pmCalculate doesn't happen in the analog domain! But please explain how a digital trigger system should work...

author: Performa01
author_rank: Super Contributor
timestamp: January 09, 2016, 09:54:30 pm
content: Quote from: nctnico on January 09, 2016, 08:57:49 pmHere is an excellent application note on this topic:https://cdn.rohde-schwarz.com/pws/dl_downloads/dl_application/00aps_undefined/Benefits_of_RTO_digital_trigger_system_2.pdfPico technology have introduced the digital trigger in 1991, using the same arguments as R&S (much later obviously).

author: Performa01
author_rank: Super Contributor
timestamp: January 09, 2016, 10:00:35 pm
content: To solve the puzzle: what does a 500MHz signal look like, when acquired with 1GSa/s ?Fist let’s have a look at the signal sampled at 2GSa/s, sin(x)/x reconstruction and vector display (500MHz_2GSa_vectors_fast_sinx)Well, the waveform looks pretty unexciting, basically the same as 250MHz would look like at 1GSa/s. But we see that despite the low trigger level of 8mV, the trigger frequency display is not even close to the true value, whereas the automatic period measurement is spot on. The automatic measurements also indicate rise and fall times of 600ps, which is almost exactly the expected value and it is quite surprising to see this so accurately measured on a scope with a specified rise time of <1.2ns.What if we lower the sample rate to 1GSa/s?In this case, the signal frequency would be equal to the Nyquist frequency of the sampling system. Look what we get (500MHz_1GSa_vectors_fast_sinx)It’s a nice amplitude modulated waveform, with a 500MHz carrier and a modulation frequency that is the difference between signal frequency and half the sample rate. This is unknown of course, but most probably less than 10kHz. The trigger frequency display is the same amount off as before, and even the automatic measurements for the transition times haven’t changed significantly.If we use dots display, now having no interpolation whatsoever, we can see the true sampled data. It’s just 14 dots per trigger event, at random amplitude. At the exact nyquist frequency we would get steady amplitude, which in turn depends on the phase relationship between signal and sample clock (500MHz_1GSa_dots_fast_sinx)Consequently, with vector display again, but this time sin(x)/x reconstruction turned off, we get another nice picture (500MHz_1GSa_vectors_fast_x)Note that trigger frequency is off as always, but automatic measurements for period and transition times are spot on.

author: Performa01
author_rank: Super Contributor
timestamp: January 09, 2016, 10:14:59 pm
content: Quote from: tautech on January 09, 2016, 08:52:02 pmProbably not. I have purchased my scope with all available options from Batronix, who is my nearest distributor here in the EU, but Power Analysis hasn’t been available back then and still isn’t today.Of course, I actually don’t really need that option, but still would have included it with my purchase, if it had been available at a reasonable price. Not sure if I would purchase it separately if it ever becomes available…

author: tautech
author_rank: Super Contributor
timestamp: January 09, 2016, 10:52:26 pm
content: Quote from: Performa01 on January 09, 2016, 10:14:59 pmPower Analysis is already installed in all new SDS2000 series units and is freely available for 30 trial uses.It's in the Utilities menu on P2 and unless you've enabled it more than 30 times you should have some Trial cycles of the Power Analysis option remaining.On P3 of Utilities/Options/ Information will display remaining free trial cycles.

author: Performa01
author_rank: Super Contributor
timestamp: January 10, 2016, 12:21:03 am
content: @ tautechYes, I have 28 trial cycles left, that’s a joke, because just accessing the menu counts as activation already. So guess how far I will get, if I actually start a review on this?I will frequently have to access all the other menus, particularly trigger, display, acquisition, measurements and cursors. Then when I go back to power analysis, another trial cycle is due.I have done absolutely nothing with power analysis yet, but still already used up 2 trial cycles. No, that doesn’t much sense nor is it great fun to work under these conditions…

author: tautech
author_rank: Super Contributor
timestamp: January 10, 2016, 12:48:23 am
content: Quote from: Performa01 on January 10, 2016, 12:21:03 amI quite agree.I've already dropped hintsat the manufacturers for your great work, so if you'd be willing to go the distance we'll see what can be done.

author: Performa01
author_rank: Super Contributor
timestamp: January 10, 2016, 01:44:06 am
content: @rf-loopSince I had to find a document that saved me the effort to explain how a digital trigger system works, please have a look at figure 6 on page 7 of the R&S application note I have linked in on my reply #176. There is a little ‘upsampling’ unit in the trigger path.If you look at the explanations together with figure 7, it should be rather obvious, what this ‘upsampler’ actually does. It performs a sin(x)/x interpolation, otherwise the overshoot in their example waveform would have been missed by the trigger system.So my fault was to think this might be also switched on/off by the sin(x)/x option in the acquisition menu, but of course it has to be in effect permanently and doesn’t affect displayed data at all, as it is in the trigger path.Anyway, if you look at the whole document, many features and benefits do sound very familiar – even though a whole different class, there are many similarities with the SDS2000…

author: rf-loop
author_rank: Super Contributor
timestamp: January 10, 2016, 09:22:31 am
content: It looks (least for me) like primary trigger (or least counter trigger) is generated from one ADC 1GSa/s data also when there is 2GSa/s in use.ADC is something like thisBecause can not know exactly in what mode they run this chip it is bit difficult to make some special test what can suspect. Perhaps system is designed for 1GSa trig and not even tried generate trig from 2GSa/s data stream. If it is designed for 2GSa/s trig then there is perhaps some bug how they pick up data from ADC for produce primary trig flag.In all images signal to CH4 is 375MHz good quality sinewave from HP8644B (Agilent)Trigger normal, edge, rising, DC2GSa/s, vectors, Sinc OFF. Trigger level as high as possible for correct and stabile freq counter.Here 57mVChanged only trigger level bit higher to 58mV and noted that freq counter start drop out.Changed trig level back to 57mV and changed Sinc ON. Frequency counter stabile and right.Changed trigger level bit up, to 58mV and noted that freqquency counter start drop.After this point I want drop samplerate to 1GSa/s and do not change anything but turn CH3 on.Note also that I have adjusted small amount signal level between 2GSa/s and 1GSa/s and between SincON and OFF so that scope give same result using p-p measurement (average)This do not change anything but with this method trigger levels where counter drops or not stay same.Input frequency of course same 375. It is now 0.75*(sampling frequency/2)!1GSa/s, Sinc OFF, vectors. Trigger level 57mV and freq counter stay stabile and correct.1GSa/s, Sinc OFF, vectors. Adjusted trigger level 1mV up to 58mV so that counter just start drop.1GSa/s, Sinc ON, vectors. Adjusted trigger level to highest level what give stabile counter. It happend at 57mV1GSa/s, Sinc OFF, vectors. Adjusted trigger level higher until counter just start dropping. Noted that level is (agen) 58mVBig question is: why it happend in same level independent of Sampling speed?It must not happend if trigger is really generated from 2GSa/s (2x1GSa/s interleaved and when interleaved ADC's are 180 degree phase shifted.) data because naturally there worst case lowest level samples are higher.Then I want look History for these things because there can see waveform adjust to trigger position. But also because normal History function is same what we also use for looking Sequence mode captured segments. (frames)This is just scope running for fill history memory.1GSa/s, Sinc OFF, vectors (lines) And here also trigger level adjusted just bit over point where we get stabile correct counter.So it is set for 58mV and we can see counter drop some amount from 375MHz (375.008 ~ 375.009 is right)Just stopped and just for one example, looked frame number 4 (waveform, segment or what ever name we give)There can see one case where it may not trig. If wave what top is around LIST OFF menu selection it do not trig, quite rare but occurs. If look nearly left side same kind of.. it still may trig. (do not look line because scope do not look it, it look sample point ans only it!)Then go forward and look bit more "frame" number 308. There is interesting situation. With veector (line) it adjust horizontal position right and between sample points just where linear interpolation go over trigger level.Frame number 308. Now Sinc ON. Note shit to right so that Sinc interpolated curve is positioned to trigger position.Still frame 308. Now display dots but Sinc still ON. Note dot position near trigger position.Still frame 308. Now Sinc OFF and dots. (now dots position iss same as with vectors (dots) display mode.Still frame 308. Now back to Sinc ON and dots. Shifted back to as images p and also n.Siglent keep original sample points and it do not produce its own fake processed sample pointsindependent of what is interpolation and/or display mode.One feature what I hope is that there is selection for highlight real sample points (specially for Sinc ON but also for vectors (lines) mode.Still stay in same captured History. Now Frame number 320.Sinc OFF, vectorsStill frame 320. Sinc OFF, display dots.Frame 320, now Sinc ON. Display dots. If look carefully there can see tiny shift to right (is it one pixel (20ps)?). Because in this linear and Sinc interpolation is very near each others in trigger position.Frame 320. Sinc ON. Display vectors.It looks like primary trigger (or least counter trigger) is generated from 1GSa/s stream also when there is 2GSa/s interleaved mode in use. I can only suspect this, and with this method can not prove it with certainty. But indirect one evidence is how frequency counter start drop out because it do not get pulses. If these pulses are generated from 2GSa/s stream there is samples over trigger level in every single signal cycle. But, with 2GSa and 1GSa it start drop out some cycles just exatly with same trigger level when signal level is around same. With 375MHz there need be big difference if look worst case for one cycle with 1GSa and with 2Gsa. Difference is big. Also I do not believe they have generated separate trig pulses for counter and for primary signal trig. And, because this believe, I think counter trigger is one acceptable evidence.(I think most know there is one ADC for two channels group. This ADC have internally 2 ADC. They can work separately giving out separate data streams (both give out 2 8bit stream) or they can operate in 1 channel mode where these ADC's are interleaved by clock (180 degree phase shift what means just inverted clock). Still they both give out 2 x 8bit data bus and whole 2GSa/s is now 4x8 bit data bus. More is explained in ADC data sheet)Ed: attached image what show fine adjust between images t and uThere can see it use 20ps fine adjust step for image. (20ps is also TFT resolution limit when 1ns/div. One div is 50pixel)

author: rf-loop
author_rank: Super Contributor
timestamp: January 10, 2016, 10:13:35 am
content: Quote from: Performa01 on January 10, 2016, 01:44:06 amIf we take this nice well known R&S application note. Look there image 7.It looks like SDS2k works more like this image left side.Primary trigger is perhaps not generated at all using over sampling and sinc interpolation there before it look if there is detected signal level => trigger level ref my images where trig start drop. (still I assume counter use generated trigger and there is not separate trig for counter and waveform capture. It this assuming is wrong, then I need push this my exercise to garbage or keep it just for fun)Here (with 2GSa/s) it do not need even oversampling. Fisrt it need use all available true sample points and not half and even with this improvement is - huge.

author: Performa01
author_rank: Super Contributor
timestamp: January 10, 2016, 01:56:51 pm
content: @rf-loopWell, with combined efforts we have finally solved this puzzle.Given all our test results and having a look at the ADC08D1020 data sheet (up to now, I didn’t know what ADC is working in the scope), it all comes together very nicely.So I try to summarize the way this scope architecture works and will simplify things by ignoring the DEMUX option with its associated DXd output ports, as the actual configuration doesn’t affect the general working principle. I will also ignore the additional memory dedicated for the digital channels, that with V2 FW can somehow be attached to the analog channels to provide a total of 35Mpts per channel.So I just say the ADC08D1020 has two ADCs, where each of them has an associated digital output port, which in turn is connected to a block of 14MB acquisition memory.Both ADCs can work in parallel for any of the two analog input channels, and the interleaved data will be output by both ports at the same time, thus making the output data bus twice as wide. So we get twice the data but also twice the memory in interleaved configuration. For screen representation, we have to combine the contents of the two memory blocks, like all even sample numbers will be found in one block and the odd ones in the other.The trigger system in contrast doesn’t care for that and is attached to the output port of the trigger channel. If this happens to be Ch. 1, the trigger system is connected to the output port of ADC1. If Ch. 2 is turned off, then its output port is providing data for Ch. 1 also, but that is not seen by the trigger system, as its data bus width remains constant. This is the same on the R&S RTO, which also uses ‘only’ 10GSa/s for the trigger system, whereas a single channel can have 20GSa/s in interleaved mode. So it is the exact same situation, except for the RTO sample rates to be 10 times higher…And yes, Siglent couldn’t be bothered to implement an upsampling circuit in the trigger system, so the left part of fig. 7 in the before mentioned R&S application note applies. That sounds a bit disappointing at first, but isn’t all that bad after all. The RTO scope claims glitch detection <50ps, which would be equivalent to 500ps on the Siglent. But Siglent only specifies 1ns, which is perfectly fine for a scope in this class.Which leads us back to the point where we started this discussion…Since we could demonstrate that sin(x)/x reconstruction is not a signal processing in the main acquisition path, nor is it in the trigger path, it is indeed more like a display option and should belong in the ‘Display’ menu.For Sequence Mode, sin(x)/x should not make any difference regarding waveform capture rate, and it should be possible to arbitrarily apply that after the capture, when we are viewing the history.EDIT: ADC08D1020 appears to be a very nice chip by the way!

author: rf-loop
author_rank: Super Contributor
timestamp: January 10, 2016, 02:13:29 pm
content: Quote from: Performa01 on January 10, 2016, 01:56:51 pmOh. I forget add to my previous msg: "ADC is something like this"(I'm not sure what it is exactly, it was only for thinking principle and how it give data out. I'm quite sure thät least it is "something like this")

author: Performa01
author_rank: Super Contributor
timestamp: January 10, 2016, 02:47:28 pm
content: Quote from: rf-loop on January 10, 2016, 02:13:29 pmOh - doesn't really matter, does it?It is quite obvious that it has to be something like this, and this 'something' is a real nice piece of silicon!

author: rf-loop
author_rank: Super Contributor
timestamp: January 10, 2016, 03:16:59 pm
content: Quote from: Performa01 on January 10, 2016, 02:47:28 pmIf think only this discussion no matter (here working principle matter)But I can not confirm exactly if it isTiADC08D1020.

author: Performa01
author_rank: Super Contributor
timestamp: January 10, 2016, 05:00:56 pm
content: Peak Detect:/Roll Mode revisitedGiven the insights gained from our previous experiments, I wanted to look at this topic once again, particularly in order to see if the 1ns glitch detection works as specified.First let’s try if we can reliably trigger on trigger conditions that are only valid for just one nanosecond. I’ve tried two different methods and used the trigger frequency display as a reference. As long as its displayed value does not drop, we aren’t losing any trigger events.An easy way to check that was using a 300MHz sinewave again and adjusting the trigger level near the top of the waveform, where the positive halfwave is just 1ns wide (Trigger_1ns)With these settings triggering is reliable and no events are missed (yes, trigger frequeny display is a bit off, but it has not dropped!). And just like all the previous tests already indicated, it doesn’t matter if we use sin(x)/x or just x as well as vectors or dots. The result is also the same regardless of the number of channels in use, it also works with a sample rate of just 1GSa/s.Also tried this with a narrow pulse at a repetition rate of 1µs. Again, we don’t lose any trigger events as long as the pulse width at the trigger level is at least 1ns (PeakDetect_1ns_1MHz_1ns)Now I change the repetition rate to 12ms, while leaving everything else just as before (PeakDetect_1ns_1ns)At a timebase setting of 2ms/div we still maintain a sample rate of 2GSa/s and a total of three pulses are displayed on the screen. They are very faint, hence barely visible, but they are there (PeakDetect_1ns_2ms)At 5ms/div, sample rate drops to 1GSa/s, but that’s no problem, as we can consitently see all five pulses (PeakDetect_1ns_5ms)At 10ms/div and a sample rate of 500MSa/s, we still don’t lose any pulses, but the amplitudes aren’t stable anymore. The trigger system quite obviously still works on the full 1GSa/s raw data from the ADC as there is absolutely no hint for losing any pulses. But it becomes also obvious, that sample data is decimated to the current sample rate (500MSa/s in this case)beforepeak detect gets access to it. This explains the discrepancy between triggering and displayed data. If you look close, according to the display, the pulse at the trigger position doesn’t quite reach the trigger level, but the trigger still fires (PeakDetect_1ns_10ms)At 20ms/div and a sample rate of 250MSa/s, we still don’t lose any pulses, but the amplitudes are pretty random (PeakDetect_1ns_20ms)At 100ms/div, we automatically get roll mode, and there things change quite a bit. Current sample rate drops dramatically to just 2MSa/s, but at the same time peak detect mode quite obviously starts working based on the raw ADC data at 1GSa/s. So we not only don’t lose any pulses – except for the occasional drop out every now and then, as can be seen in the left of the screenshot – but amplitude levels are all near the maximum with only little variation (PeakDetect_1ns_100ms_roll)Finally I want to push this to the limit and use 50s/div roll mode, which is the maximum we can get on the SDS2000. Sample rate now drops to the incredible low value of just 4kSa/s, but we still see a dense carpet of pulses that are only 1ns wide at the trigger level! (PeakDetect_1ns_50s_roll)The question remains: does it really capture all the pulses without missing any? Short answer is yes, it does. When stopping the acquisition and lowering the timebase to 10ms, we can see all the pulses there, even at a fairly constant amplitude. Yes, I’ve shifted the waveform on the time axis a bit in order to find any missing pulse, but they were all there (PeakDetect_1ns_50s_H10ms)I’ve also tried that in Y-t mode at 100ms/div and – surprise! – it behaves the same as roll mode, i.e. despite the sample rate now being 50MSa/s, we get all pulses at their full amplitude. So it quite obviouslyispossible to do the peak detectbeforedata decimation, so that we can get the true peak data values based on the raw 1GSa/s ADC data, no matter what the current sample rate (that determines the time spacing of the samples in the buffer) is (PeakDetect_1ns_100ms)Conclusion:Peak detect works absolutely perfect in roll mode and generally for time bases >20ms/div.Below that, it seems there would still be room for improvement. As it is now, the peak values are acquired from simply decimated data according to the current sample speed, instead of replacing the decimation by a peak detect mechanism.As it is now, if we had a perfect 1ns wide pulse we would be able to trigger on it but still might not see anything on the screen.Big question:Since it is possible to do it in an optimal way for timebases >20ms, why on earth has it to be different for faster timebases?

author: Performa01
author_rank: Super Contributor
timestamp: January 16, 2016, 06:37:41 pm
content: Digital Trigger System, Peak Detect & Glitch CaptureAfter a little pondering and some more tests, I should provide some clarifications on the digital trigger system, glitch capture and peak detect acquisition mode, also with regard to the observations described in my recent postings.First, I shall give an overview on how the SDS2000 works, see picture SDS_BD.The input signal is conditioned by means of an attenuator and VGA /variable gain amplifier) to accommodate the dynamic range of the ADC.TheADCis clocked at a constant 1GHz, hence provides a constant sample rate of 1GSa/s. To keep things simple, the block diagram doesn’t include interleave mode, where the ADC data of two channels are combined in order to yield twice the sample speed, because this has no impact on the basic operation and particularly the trigger system, which always works with 1GSa/s raw data from just one ADC – the one that is assigned to the trigger channel.The ADC always has to run full speed, otherwise the fully digital trigger system as well as the 1ns glitch capture would not work. So I refer to the ADC output as the raw sample data here. These are fed into the trigger circuit and the first signal processing unit at the same time.Proc. 1refers to the first signal processing step, which serves (at least) two tasks:1. Compaction of the raw sample data according to the timebase setting, so they can fit into the available sample memory.2. Glitch capture, which is similar to peak detect, with the only difference that it works on the raw sample data instead of the already decimated data in sample memory.Of course, compaction is only necessary on timebase settings, where the raw sample data for the full screen width don’t fit into the sample memory. For example, at the lowest memory setting of 7k no compaction is needed for timebases up to 500ns/div, because this results in a total recording time of 14 div. times 500ns = 7µs, which in turn yields 7k samples at 1GSa/s.For slower timebase settings, the amount of data has to be reduced in order to fit into the memory. This could be done by simple decimation, i.e. writing only every Nth sample into memory. This way, a slower sample speed is simulated and I’ll refer to it as the effective sample rate as opposed to the raw sample rate, which is always 1GSa/s.Since this scope provides glitch capture down to 1ns, a simple decimation would not cut it at all, hence a similar process as described below for the 2nd processing step in peak detect mode has to be applied in order to preserve narrow glitches and make sure they will make it to the sample memory.Proc. 2refers to the second signal processing step, which has to do one more data compaction in order to fit the display. As the display has 800 x 480 pixels, we can assume there are 700 horizontal pixels for the waveform. In normal acquisition mode, we can only sensibly display 700 pixels per waveform. Even if the sample memory is at its lowest setting of just 7k, this is still 10 times more than what the display can handle. In normal acquisition mode again, the 2nd signal processing step would just decimate the data by only passing every 10th sample to the display.In peak detect mode, things are a little different. It should be obvious, that peak detect mode wouldn’t make any difference as long as all data in memory fit into the display memory. So at timebase settings of 50ns/div or faster, there are just 700 samples (or less) acquired for each trigger event (waveform), so no data compaction is required, no matter what the memory depth is set to.If the sample memory contains more than 700 samples for a single waveform and data compaction becomes necessary, peak detect mode traditionally uses two data points, that is a minimum and maximum value, per horizontal pixel on the screen. So at a timebase of 100ns/div there are 1400 samples per waveform, and they all make it to the display in peak detect mode, as there is now a min/max data pair for each horizontal pixel position.For even slower timebases, peak detect keeps providing the display with 700 data pairs, so it needs to do some data reduction too. But this time it isn’t just dropping superfluous data by a simple scheme without looking at them, but every cluster of samples that shall be displayed at just one horizontal pixel position is searched for the min/max values and the resulting data pair is sent to the display.By now it should be clear, that peak detectandglitch capture together give an extremely powerful combination, which allows us to spot narrow pulses down to 1ns width even at very slow effective sample speeds, such as in roll mode, where it can be as low as just 10Sa/s at 50s/div with 7k memory.So now let’s correlate the findings in my previous tests with the working principle described above:Conclusion1. The trigger system works flawlessly on trigger events down to 1ns, no matter what the timebase and acquisition settings are, except for the minor flaw that it won’t trigger correctly on two narrow pulses spaced <30ns apart, as I’ve demonstrated in an earlier post.2. Peak detect mode works just as it should and I haven’t come across a single instance, where it had failed to do so.3. Glitch capture works beautifully on slower timebases, but doesn’t seem to work properly on faster ones. This needs some further investigation (coming soon).EDIT: some typos...

author: Performa01
author_rank: Super Contributor
timestamp: January 16, 2016, 08:33:01 pm
content: Glitch CaptureIn all previous tests, triggering and peak detect worked absolutely fine, whereas glitch capture quite surprisingly only kicked in at timebases 50ms/div and slower, leaving two timebase settings (10 and 20ms/div) where the pulses had a pretty random amplitude, indicating that they were captured only with the effective sample rate of 500 and 250MSa/s respectively.This behaviour gave me some headache, since it should be clear what would happen if we had a perfect 1ns wide pulse.The scope risetime is specified at <1.2ns (it is actually more like 1ns), so the ADC in a SDS2304 would probably see something like this when a perfect 1ns wide pulse is applied to the scope input (Ideal_Pulse_1ns)That means at a sample rate of 500MSa/s the minimum pulse hight on the screen would be just about 15% of the original amplitude. With 250MSa/s, it could easily happen that the pulse wouldn’t be visible on the screen at all, whereas the scope would still reliably trigger on it. That’s certainly not good – we always should be able to see the trigger event, i.e. the signal the scope has triggered on.The test I am referring to has been carried out with the maximum memory length of 70Mpts. What if we select less memory, which would cause the sample rate to drop earlier? For example, with the minimum of 7k, sample rate would only be 25kSa/s at 20ms/div and glitch capture would not work for all timebases from 20ms/div down to 1µs/div! This prospect gave me some serious headache, so I had to investigate.I set up another test with narrow pulses, but this time wanted to demonstrate glitch capture working independent of the trigger. So I let the scope trigger on a sync signal applied to Ch. 3, whereas the narrow pulses are fed into Ch. 4 with some 30ns lag with respect to the trigger edge. Peak amplitude is about 4.5V and pulse width is <4ns (Glitch_Test_Setup)I’ve tested all possible memory sizes and will show a few examples only.First 7k memory depth and 500ns/div, which still maintains 1GSa/s (Glitch_7k_1GSa)Everything’s fine here, as the sample rate has not yet dropped. A little amplitude jitter is inevitable, given the fact that 1GSa/s isn’t fast enough to consistently capture the pulse peak. I’ve turned automatic measurements on, in order to document my observations and according to these, the pk-pk amplitude varied by just 240mV, equivalent to some 5%.At 1µs/div and with 7k memory, sample rate drops to 500MSa/s and since the pulse is significantly wider than 1ns, the variation still doesn’t appear too bad, it is now 680mV or 15%. In any case, glitch capture has not kicked in (Glitch_7k_500MSa)At 2µs/div and with 7k memory, sample rate drops to 250MSa/s and the amplitude variation gets really significant now – it is 2.48V or 54%. No glitch capture to be seen … (Glitch_7k_250MSa)At 5µs/div and with 7k memory, sample rate is now down to 100MSa/s, but glitch capture has finally become active. The amplitude variation gets significantly better again with 1.12V or 24% (Glitch_7k_100MSa)And it gets even better at slower timebase settings. As an extreme example, at 20ms/div and with 7k memory, sample rate is only 25kSa/s, but glitch capture is quite effective here. The amplitude variation is a negligible 120mV or 2.6% (Glitch_7k_25kSa)As already stated, the behaviour is basically the same, no matter what the currently effective memory depth is. But there is one exception with the maximum setting of 35Mpts, because it allows a timebase setting, where the sample rate drops to just 125MSa/s (Glitch_35M_125MSa)As can be seen from the screenshot, amplitude variation gets particularly bad here and we do indeed see some missing pulses (we can see that we can see nothing). So far this is no big surprise, as it seems obvious by now, that glitch capture only kicks in for sample rates of 100MSa/s and slower, and sampling a pulse that is less than 4ns wide at only 125MSa/s cannot yield any useful results of course.Apart from that, the additional memory once again seems to cause some additional trouble as well (as I’ve already demonstrated when reviewing the FFT), as now the automatic measurements don’t show the true picture at all. According to these, the minimum amplitude would still be 3.76V, which is clearly not true as the signal trace indicates.ConclusionGlitch detect only kicks in at sample rates of 100MSa/s or slower, leaving a gap for the timebases where the sample rate is more than 100MSa/s, but still less than 1GSa/s. In this area it actually could happen that we might not see the trigger event on the screen. This is clearly a flaw, but is easily circumvented by avoiding this ‘grey’ range of sample rates when really narrow glitches can be expected to occur. Maybe Siglent could narrow or even close this gap?Maximum memory enables us to get a sample rate that is just slightly faster than 100MSa/s (where glitch capture would kick in), with particularly bad results, but also causes the automatic measurement to apparently miss all peak amplitudes lower than 3.76V in my test setup, that is clearly a bug.I can withdraw another complaint in exchange, namely the very striking double lines (I called it ‘ghosting’ back then), specifically in roll mode. This is simply the visual effect of glitch capture and naturally gets worse with increasing ratio of raw to effective sample rate. Since the effective sample rate drops dramatically in roll mode, this explains why the double lines become so obvious in this mode.Well, one might still ask why the effective sample rate has to be that slow and why sample memory is limited to 1.4Mpts in roll mode. But that’s another storyEDIT: corrected prediction of the response to an ideal 1ns pulse.

author: Mark_O
author_rank: Frequent Contributor
timestamp: January 17, 2016, 07:17:55 pm
content: Quote from: Performa01 on January 16, 2016, 08:33:01 pmOne problem there is that sometimes I'm not expecting there to be any really narrow glitches at all. However, that does not stop them from occurring.And it's one reason I may be using a scope... to check to see if things are occurring that Idon'texpect. As in, shouldn't be there, but are. I'd rather not have to avoid a 'grey range', which hasn't even been defined by the manufacturer.[Exceptional continuing analysis, BTW.]

author: Performa01
author_rank: Super Contributor
timestamp: January 17, 2016, 11:43:57 pm
content: @Mark_OIn general, I agree with you – and that’s the reason why this topic gave me some serious headaches and kept me investigating.Nevertheless I should try to explain a little better what I had in mind when talking about ‘expectations’ with regard to narrow glitches.Glitch capture does not work at sample rates >100MSa/s, so in general a potential problem exists for pulses <10ns wide.The lowest sample rate >100MSa/s we can actually get is 125MSa/s at 35Mpts, which corresponds to a pulse width of 8ns.For all other memory settings, from 7k to 28M, the lowest sample rate >100MSa/s is 200MSa/s, corresponding to a pulse width of 5ns.That means, for all possible combinations of timebase and memory settings but one, the pulse width has to be less than 5ns in order to be able to cause a problem. Yet there is one single setting, where this limit is 8ns.So I just wanted to point out that there is a physical limit to how narrow a pulse can be produced by any circuit, be it by intention or by accident – and that’s the bandwidth / transition times of active components in use.For example, for logic devices with slow transition times, like TTL and LS-TTL, as well as CMOS up to HC, it would be very unlikely for a narrow pulse <8ns to occur. Of course, it is not totally impossible and could still happen at a very low amplitude, but then we would miss it anyway, as long as the trigger level is set to the nominal threshold voltage of ½ Vdd for CMOS. And as soon as we need to set a specific trigger level in order to capture the glitch (which would be totally different depending on the initial logic state), we need to be aware that there is something going on, and if so, we can just as well set up the scope so that it uses its full sample rate – which should be easy, given the amount of memory available.So this is basically a problem for high speed logic debugging only, as I cannot think of any mechanism causing sporadic narrow glitches in analog circuits, including HF designs and discrete transistors, and I’ve certainly never observed one in some 40 years. This is what I mean that we can indeed expect – let’s say ‘predict’ instead – whether or not glitches could occur and if so, what the minimum pulse width would be for a given circuit.Btw. I have corrected the paragraph describing the effects of an ideal 1ns wide pulse in my previous post, as it is obvious that the rise time of the scope alone will prevent that pulse from disappearing completely at 500MSa/s. For the same reason, this whole topic wouldn’t be an issue on a 100MHz scope.Apart from all that, it shouldn’t be impossible to fix this issue in the SDS2000(x) V2 firmware and I certainly hope that Siglent engineers will come up with a working solution.

author: Performa01
author_rank: Super Contributor
timestamp: January 31, 2016, 01:02:29 pm
content: Visibility of narrow pulsesFor several tests I’ve used narrow pulses and sometimes pointed out that they were barely visible in the screenshots. This might lead to the false impression that it would be generally difficult to spot glitches on the scope screen, which isn’t true. So I thought I’d elaborate on that a bit more.Generally, it should be obvious that narrow pulses appear on the screen as lines that are only one or two pixels wide, hence visibility also depends on the absolute screen resolution. The screen on the SDS2000 has an absolute resolution of about 114dpi which corresponds to a pixel width of ~222µm. This is not awfully big…My computer screen where I’m viewing the screenshots has only ~81dpi and the pixel width is ~312µm and visibility should be better, but that’s not actually the case. In fact, visibility is significantly better on the scope than the screenshot viewed on my computer monitor. The reason for this is in the monitor profile, including settings for brightness, contrast, gamma and color space, which are optimized for natural looking photos as I do a lot of picture processing. It is obvious that the scope uses a quite different profile, optimized for graph viewing.So it comes as no surprise that visibility of glitches is not bad on the scope, whereas it might be considerably worse on the computer screen, depending on the monitor profile in use.That said, I still did a couple of tests to determine how the display of glitches can be improved.First I show a screenshot with the default settings on the scope. Depending on your particular monitor settings, visibility of the narrow pulses on channel 4 as well as the edges of the squarewave on channel 2 might be somewhere in the range of fair to poor (Glitch_Intensity_Grade_50%)Of course, the narrow pulses and steep edges are so dim because of the intensity grading and in situations like this, one might wish to be able to turn it off. Intensity grading simulates the behaviour of an analog scope, which gives us a lot more information about dynamic signals, but also has the disadvantage of poor visibility of fast edges, if not quite as bad as it used to be in the CRT era.We cannot turn off the intensity grading.Persistence doesn’t help either.We can only turn up the intensity of the trace display (Glitch_Intensity_Grade_100% )Visibility has clearly improved and might be all you’d ever want on the scope screen, but might still not be enough for the screenshot image. Even when the monitor picture is acceptable, one might still want better visibility when including screenshots in printed documents – without the need to post process the images, that is.This is a situation where color grading as an alternative to intensitiy grading comes in really handy (Glitch_Color_Grade)Yes, it might not look as pretty as before, but it maintains all the information of the 3rd dimension (intensity) without visibility problems. Even when I’ve stated some time ago that I don’t care for color grading, I’ve been disabused and by now be grateful that Siglent has implemented this display mode.

author: Mark_O
author_rank: Frequent Contributor
timestamp: February 01, 2016, 10:53:27 am
content: Re: narrow pulse visibility on various screens...Quote from: Performa01 on January 31, 2016, 01:02:29 pmI noticed exactly the same behavior, while I was evaluating the SDS1000X series. On-scope visibility fine, but visibility of traces on my PC screen substantially worse. The way I dealt with this was simply to run my screen shots through IrfanView [a free PC app], and apply an Auto-Color Adjust to them (which I can easily do in batch-mode). This was a quick one-step process, which improved screen captures significantly.Attached is an example of your initial screenshot, adjusted:[Updated to put a copy of your original underneath, to avoid having to scroll back and forth to compare.]On my PC screens at least, this looks better than even your 100% Intensity version. Plus a side benefit is the fact that it also brings up other areas of the DSO screen, like the shading on the buttons, top bar, and side boxes, which tend to vanish on the raw snapshots (which also don't look as good as they do on the scope itself).

author: Performa01
author_rank: Super Contributor
timestamp: February 01, 2016, 04:05:55 pm
content: @Mark_OOh yes, this looks a lot nicer indeed!Actually I have to batch process all screenshots anyway, in order to convert the big bitmap files to PNG. I'm using Photoshop for this - next time when I have to convert some screenshots, I will see what can be done to resemble the look of the scope screen on an average computer monitor...

author: nctnico
author_rank: Super Contributor
timestamp: February 01, 2016, 06:18:57 pm
content: Why do you save them as bitmaps? PNG is lossless for these kind of images!

author: Mark_O
author_rank: Frequent Contributor
timestamp: February 01, 2016, 07:13:02 pm
content: Quote from: nctnico on February 01, 2016, 06:18:57 pmWe are saving them as PNGs. At least that's what I've always done, after conversion.But they come out of the 1000X only as BMPs, and I assumed that was true of the 2000 as well. Perhaps not.

author: nctnico
author_rank: Super Contributor
timestamp: February 01, 2016, 07:44:24 pm
content: Quote from: Mark_O on February 01, 2016, 07:13:02 pmThe SDS2000 screendumps I have are BMPs indeed! I forgot about that and naturally assumed a scope from this day and age uses JPEG or PNG for screendumps and not an ancient and inefficient format like BMP and not even using (RLE) compression.

author: Mark_O
author_rank: Frequent Contributor
timestamp: February 01, 2016, 09:03:08 pm
content: Quote from: nctnico on February 01, 2016, 07:44:24 pmWell, there's always a tradeoff. While the vastly smaller PNGs would write out to a memory stick a lot faster, it might take the CPU in the DSO longer to convert from BMP -> PNG than the time saved! Since high capacity USB sticks are so cheap now, it hasn't bothered me all that much to be dumping BMPs. I do agree though that RLE would be an obvious compression, which should be both easy to implement and fast to perform. Still, not as easy as simply dumping the raw bit-map, which gets the job done.On my WaveRunner I can basically write snapshots in about any graphic format I want, so I do PNGs there. But that's really a PC in DSO clothing, so it has the horsepower to do that fairly effortlessly (along with a price-tag considerably higher than any of the Siglents).I think we need to pick what we want to complain about, and for me this wouldn't be it. I'm not sure what other affordable scopes"from this day and age use JPEG or PNG for screendumps". Perhaps you could cite a few?

author: nctnico
author_rank: Super Contributor
timestamp: February 01, 2016, 09:15:26 pm
content: My new Gw Instek GDS2204E for example saves screendumps instantly (less than a second!) in PNG format. The largest screendump I can find is 32kB and mind you: the GDS2204E also has a 800x480 screen just like the SDS2000! Sending a few screendumps in an e-mail (which I do regulary) is much easier with images which are a tens of kB than having to send several MB or needing to convert the images first.

author: Mark_O
author_rank: Frequent Contributor
timestamp: February 02, 2016, 11:00:27 am
content: Quote from: nctnico on February 01, 2016, 09:15:26 pmThat is excellent. And it's not the only thing that Instek has done well on the 2000E series. Their post acquisition Search capability is unique in it's price class, and something the competition should wake up and emulate.But I was wondering about how other existing DSOs handled this, and the relatively new GDS-2000E didn't answer that. I know from using them that both the Agilent X2000 and X3000 series (DSO's and MSO's) all support PNG format output. So I checked on the Rigol's, and was a bit surprised to find that the 1000Z and 2000A both support a broad range of screen image formats: “.png”, “.bmp8”, “.bmp24”, “.jpeg” or “.tiff” format!So yes, your comment that the Siglent's handle only BMP format is a valid criticism, when compared against competitive units.QuoteAbsolutely no doubt about that. I'd never ship a BMP, but the extra step of running it through a converter is certainly a small hassle I could do without. And since even the cheapest Rigol can manage PNG (and much more), I think Siglent should seriously consider rectifying that. [ADDED: And even if the Crunch+Save wound up taking longer than the current RawSave, I think it would be worthwhile, simply from the convenience standpoint.]But I still don't think it's a huge consideration.

author: F5D
author_rank: Newbie
timestamp: April 11, 2016, 05:58:54 am
content: Any news of a new firmware version with bugfixes? Looking for a new scope and the SDS2000X hardware seems like a very good contender. However, would be nice to have the ERES and FFT working well, before making the decision. I believe the X-model uses the same firmware as the 2000?

author: tautech
author_rank: Super Contributor
timestamp: April 11, 2016, 07:49:21 am
content: Quote from: F5D on April 11, 2016, 05:58:54 amNote quite the same, there are different versions for each of the 1000X, 2000X and 2000 series.Re new 2000X FW, later today is what I've just been informed.Check here:http://www.siglentamerica.com/support_software_15http://www.siglenteu.com/gjjrj.aspx?id=15http://www.siglent.com/ENs/gjjrj.aspx?id=15

author: tautech
author_rank: Super Contributor
timestamp: April 13, 2016, 03:22:10 am
content: New FW for the SDS2000 (not X) series:http://www.siglentamerica.com/USA_website_2014/Firmware&Software/firmware/SDS2000%20P3301.rarFrom the 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 > 1024Editfix URL

author: rf-loop
author_rank: Super Contributor
timestamp: April 14, 2016, 03:07:15 pm
content: Small improvement-bugfix in serial decoding.It is not yet free of all bugs. One example is in image. When there is RX TX and here example TX (in this case CH2) is shut off it copy CH1 (RX here) to TX.But, overall it works nowlotof better!Now it can decode and display also ASCII as also HEX and Binary.Hope they later do some finishing for visibility including also font in decode displays.

author: rf-loop
author_rank: Super Contributor
timestamp: April 20, 2016, 12:30:37 pm
content: Quote from: Performa01 on January 07, 2016, 04:32:24 pmIt strongly looks like that last FW update have changed this. I have not now enough time for test it using SDS2304 but with tiny fast test with SDS1202X give sign that now it overlay all acquired segments in sequence to display after sequence is ready. And fast look with SDS2304 looks like doing same. But, this lounge is not free. Price is that it need more process time between sequences depending amount of segments in sequence and also depending display settings.But, imho this is low price for this improvement.

author: Performa01
author_rank: Super Contributor
timestamp: April 20, 2016, 01:01:53 pm
content: Quote from: rf-loop on April 20, 2016, 12:30:37 pmSo this might be item e) from the changelog?e) All frames are not mapped to the display in sequence mode with frames quantity > 1024I think dead time in sequence mode is not that important anyway, as the whole idea of sequence recording is to capture any rare event within one sequence. Obviously, when we set up a sequence recording, we already need to have an idea of what we're trying to capture, so we can choose the parameters such as timebase and memory depth (which in turn determines the maximum acquisitions in the sequence buffer) appropriately.On the other hand, if all buffer data is mapped to the screen and if the average trigger rate is actually higher than in standard recording mode (just with background history), it might have some uses in glitch finding.That being said, I'm not a huge fan of the waveform update rate hype with some made-up test scenarios. Up to now I've always found other means to isolate glitches. But then again, a reasonable fast update rate does have its charm, particularly when the mask testing works the same speed, as is the case with these scopes.I have not updated my SDS2304 yet, but will certainly do within the next couple days and then have a brief look at what Siglent have given us.

author: rf-loop
author_rank: Super Contributor
timestamp: April 20, 2016, 01:24:34 pm
content: Quote from: Performa01 on April 20, 2016, 01:01:53 pmYes, roughly agree.But I see it important if all segments are mapped to display after sequence ready. This way after sequence is easy to see if acquired segments have some anomalies. (I do not mean "usual" thinking about rare random glitch hunting)What I hope Siglent also improve. History view function need develop so that there is more tools. When we stop scope for looking normal bacround stored history or sequence mode captured segments I hope they add user adjustable cumulative overlay mode when run playback and/or least persistence in playback. Even many old HP have this overlay mode when playback stored segments. Fast way to look if there is anything what need look more deeply.

author: Performa01
author_rank: Super Contributor
timestamp: April 20, 2016, 02:00:55 pm
content: Quote from: rf-loop on April 20, 2016, 01:24:34 pmI fully agreeSorry if it sounded like I wouldn't appreciate the fact that now all data are mapped to the screen - of course I do! After all - like you said - we can see any anomaly at a glance and can thus decide whether it's worth investigating the sequence buffer.Yes, analysis tools - there has already been something in that direction in the V1 FW if I remember correctly. But this is an area where we should start thinking from scratch what would be really useful.Search for arbitrary trigger conditions and/or retroactive mask test within the sequence/history buffer might be a first idea. But with all data mapped to the screen now anyway, we could just set up the trigger or mask test without even looking at the sequence buffer and then run another test to find the abnormal acquisition...

author: timofonic
author_rank: Frequent Contributor
timestamp: April 29, 2016, 08:47:46 am
content: Any crazy mind wish to compare Rigol vs Siglent?

author: rf-loop
author_rank: Super Contributor
timestamp: April 29, 2016, 09:27:46 am
content: Quote from: timofonic on April 29, 2016, 08:47:46 amAnd comparable Rigol is what? Of course also boot and shoe can compare but...If buyer is thinking between example Rigol DS1000Z or DS2000A and Siglent SDS2000 or 2000X he do not know what he need. There is tens on different scopes what can infinitely compare and compare and then also frequently come new models and also FW's and features are all time changing so really important thing is get answer to question "What I really need?"

author: tautech
author_rank: Super Contributor
timestamp: May 17, 2016, 08:12:49 pm
content: Here's a vid demonstrating the V2 FW Sequence Function with a SDS2000X series DSO:https://youtu.be/nZTQBi4PAkg

author: tautech
author_rank: Super Contributor
timestamp: June 28, 2016, 08:41:41 pm
content: New FW released for SDS2000 series....notXVersion: P38.7http://www.siglentamerica.com/USA_website_2014/Firmware&Software/firmware/SDS2000-firmware-P38.7.rar3.4 MbChangelog from the website:1. Supported measurement in Roll mode at run state2. Added slew rate+ and slew rate- measurement parameters and Updated the description of some parameters3. Disabled insignificant measurements on FFT4. Fixed some bugsa) Incorrect timing in finite persistence modeb) Values change on trigger delay, level, offset etc. when adjusting horizontal, offset and level position back and forwardc) Unmatched side lobe suppression with blackman or hamming windows in FFT moded) Skew between analog and digital channels out of spece) Freeze problem in some specified casef) Measurement statistic does not Update in some casesg) Incorrect measurement on ROV?FOV?RPRE?FPRE

author: TheDefpom
author_rank: Frequent Contributor
timestamp: July 18, 2016, 10:29:59 pm
content: I have been using my SDS2102 the past couple of days on the latest firmware, using my logic probe function (digital), and have found several little bugs.When viewing digital, and the B1 line at the bottom of the screen shows the value, if you zoom, the line does not expand with the sample (as shown in first 2 images, so you cannot zoom into the value.When switching zoom on and off, of you were set to low in the channel height setting (to fill the screen), it forgets that when turning zoom back off, and goes back to middle.If you then set the height to low again, and there is a sample on screen, the sample stays at the middle point, whilst the lines move to the low one (it may also do this in reverse, I didn't try).If using Normal triggering, to get a sample at each change, and you try to adjust the timebase to be 50ms (more than 20ms), the digital turns off, and it goes to auto triggering, when turning back to 20ms it stays on auto triggering (why does it change trigger modes?), also if the Source menu is not being displayed at the time, it also forgets which triggering input that was selected, and swaps to CH1 instead of whatever digital channel was selected, even when switched back to digital.I wish the digital did not stop at the 20ms time, and allowed it to sample for longer time periods, it shows as 14Mpts being used, but the scope is capable of more than that, even if it reduced the sampling frequency in order to get a longer capture time.I also noticed that even though I had turned off lines D5, D6, D7, somehow they got turned back on again, I didn't notice when.

author: tautech
author_rank: Super Contributor
timestamp: July 18, 2016, 10:57:36 pm
content: Thanks ScottWhen using slower than 20ms the scope goes into Roll mode but if you stay at 20ms and then if using the Zoom function the zoomed traces can be displayed at slow timebases as seen in your #5 image.If you can add the image # to the text it may make things a little easier to follow.I've just got a SDS2kX series (very similar) with MSO so I can work through these issues with you if that's any help.Maybe we can do a workshop at your place to zero in on any issues?Rob

author: TheDefpom
author_rank: Frequent Contributor
timestamp: July 18, 2016, 11:11:33 pm
content: I also just found this bug... at a certain timebase (500us) it glitches the display, showing high and low states at the same time, until you change the timebase to 200us, and then switch it back to 500us again, then it displays correctly, odd.I just adjusted the memory depth to 14M (it had reduced itself to 1.4M) and the glitching went away, I also noticed the sample was not actually correct, as it is supposed to trigger on D0, and yet there was data showing before D0 ? closer inspection shows the data to be garbage.

author: tautech
author_rank: Super Contributor
timestamp: July 18, 2016, 11:38:13 pm
content: I see some triggering issues, you have selected CMOS levels and rising edge, is this appropriate?Are the TTL or User defined trigger settings better?

author: smarteebit
author_rank: Contributor
timestamp: July 19, 2016, 01:11:40 am
content: I'm waiting for nctnico pouring oil on the flames. That should be funny.

author: nctnico
author_rank: Super Contributor
timestamp: July 19, 2016, 01:22:08 am
content: Quote from: smarteebit on July 19, 2016, 01:11:40 amI just sit and watch the sad story continueIn a contorted way I'm glad I got so angry that I dumped the SDS2000 and bought some different scopes which just work otherwise I'd be like this:

author: tautech
author_rank: Super Contributor
timestamp: July 19, 2016, 06:16:37 am
content: Quote from: TheDefpom on July 18, 2016, 11:11:33 pmScott, from the info we have above I have some feedback from Siglent.First Roll mode.Particular to the SDS2000 series we know that Roll mode isauto engagedat slow timebase settings.This can be overridden in both the 2000 and 2000X but each with a different method.SDS2000: Select Horizontal key and then YTSDS2000X: Select Roll key and toggle between Roll and YT modes.Observed high and low glitches. (screenshots)When the screenshot is taken (we think due to the display update) we get a displayed state where the high and low states at the same time are captured but not all the time or repetitively.Stopthe waveform for confirmation of the correct waveform.As for the other decoding issues they are decoding setup as discussed privately and you've indicated that you'll do more with decode in the following days.

author: TheDefpom
author_rank: Frequent Contributor
timestamp: July 19, 2016, 07:02:51 am
content: Thanks for the feedback.The display glitch shows up on normal trigger mode (taken 1 sample only) so it is not an issue with repeated triggering causing a doubled display), it is only triggering once in this case.

author: TheDefpom
author_rank: Frequent Contributor
timestamp: July 19, 2016, 08:09:26 am
content: I am just doing some more testing, if I stop the scope (from in Normal triggering), the data at the bottom does indeed scale with the sample (it does not do this when in normal trigger mode and has only been triggered once, displaying the same sample).If I stop the scope when I have the glitch present, the glitch goes away, in the same was as if I change timebases, OR if I adjust the trigger position in either direction.HOWEVER, the sample displayed is not correct, if you look at the first screen shot below, this sample is at 1ms, that is the true sample taken, the second screen shot (under exactly the same conditions, same sample etc) with a faster timebase of 500us if very different, not just twice is big, as you would expect it to be, as per the third screen shot, which is the 1ms sample, stopped and with the timebase increased to 500us (to be effectively the same), these are all set at 1.4M memory, which is when the glitch occurs (it doesn't do this at 7M etc)Also I checked the YT vs ROLL setting, I already have it set to YT, perhaps this setting should "stick" regardless of timebase setting, so it stays set on the selected mode (digital) triggering, and trigger input. Don't forget it also changes the trigger input from my configured D0 inpu, to CH1 and jumps to auto triggering at the same time, even if I put the timebase back to 20ms CH1 stays, as does Auto trigger (but it does turn digital back on), basically it fails to remember the set configuration and return to it properly, it goes to some kind of defaults overriding what was set, ideally it try to be less smart here, and lets me do what I am trying to do, even if it will be slow to update the screen, I tried setting YT at the slow timebase and then set my trigger back to normal, and the trigger input back to D0, it works fine (but slow as expected).

author: TheDefpom
author_rank: Frequent Contributor
timestamp: July 19, 2016, 08:25:48 am
content: Also, if you look at the glitched screen shots, it looks like it is overlaying two samples of two different timebases, as they line up perfectly with some of the sample at the other timebase.

author: TheDefpom
author_rank: Frequent Contributor
timestamp: July 19, 2016, 08:47:15 am
content: And a bit more info, that glitching is happening at any timebase faster than 500us, IE 200us, 100us 50us, 20us, 10us etc.

author: tautech
author_rank: Super Contributor
timestamp: July 19, 2016, 09:02:47 am
content: Quote from: TheDefpom on July 19, 2016, 08:47:15 am@ what memory depth?

author: TheDefpom
author_rank: Frequent Contributor
timestamp: July 19, 2016, 09:27:00 am
content: At 1.4M anything under 500us glitches, at 7M for anything under 200us (glitches), at 14M anything under 100us glitches.

author: Performa01
author_rank: Super Contributor
timestamp: July 22, 2016, 09:58:47 pm
content: I’ve tried to replicate the issues reported by TheDefpom and here are my findings:Bug: Bus Decoding doesn’t follow timebase changes while trigger state is “Ready”Changing the timebase while the scope is not stopped and the trigger is ‘Ready’ does indeed redraw the traces, but not the (parallel) bus decoding. We do not recognize this on a continuously triggered signal, as the decoding will fit the timebase on the next valid trigger. It also works as it should in Stop mode. A minor bug in my book, but a bug nonetheless.Bug: Channel height setting is not preserved in Zoom modeWhen entering Zoom mode, the digital Channel Height is always automatically set to “Middle”, no matter what it has been set before. We can change Channel Height back to “Low” while in Zoom mode and it stays that way after returning to normal mode.However, I did not observe any mismatch between legend and traces after altering the Channel Height on an SDS2kX series scope, so this phenomenon must be specific to the SDS2k firmware.As far as the X-series is concerned, this is again not a show-stopper, but for that matter:Bug: Channel Height menu itemsThe Channel Height Menu offers three settings: Low, Middle High.First of all, I would change “Middle” to “Medium”, since we’re talking about a height and not a position here.Secondly, I think the assignment is wrong. If we select “Low”, we get high traces, and we get tiny ones if we switch to “High”. That’s counter-intuitive.Flaw: Roll Mode with digital channelsNow for the time bases slower than 20ms/div. This scope has the habit to automatically switch to roll mode for time bases of 50ms/div or slower. In some cases this is handy, in most others it is rather annoying. Roll mode is not a triggered operation, so it’s all the more funny that the scope changes trigger to analog channel 1 and starts showing the yellow trigger level indicator when it enters roll mode of all things.At the same time, digital channels are turned off. This should be okay, as probably not many of us urgently want to watch digital signals in slow untriggered roll mode anyway. The cure is simple: just switch the scope back to y-t mode and the digital channels as well as the trigger will be back to how it was before. The scope now stays in y-t mode until next time we cross the 20-50ms/div border, which is indeed a bit annoying. Since roll mode doesn’t work with digital channels anyway, it should be permanently disabled as long as digital channels are active.As a side note, with firmware P38.7 roll mode only works as described in the manual (and as we are used to it) when in auto trigger mode. In normal or single trigger mode, roll mode is actually triggered. This might be useful for some rare applications and that’s why I’m willing to look at it as a feature rather than a bug, but this behavior has to be documented in the user manual.Bug: Exiting Roll mode switches trigger to AutoThis is clearly a bug and I’ve reported this already.? Disabling individual digital channelsI could not replicate that on an X-series scope. So maybe once again an SDS2k specific issue?? GlitchesI cannot replicate any of the glitch issues. When looking at the screenshots, e.g. in Reply #223, I don’t see anything unexpected. A fundamental rule for getting a stable picture on a scope is finding a stable trigger condition that is unique within one acquisition. However, this data pattern has no such unambiguous trigger condition. Triggering on D0 will give the worst possible result, as the trigger condition is met several dozen times within the signal packet. Triggering on D2 should already give significantly better results and the best approach would be a pattern trigger on D0 AND D2 HIGH, but even this is not unique, as it appears again right after the D0 burst. So depending on the timebase, this might still lead to unstable triggering and consequently various superimposed traces from different acquisitions.So either find another signal for the trigger, that clearly indicates the start of the signal packet, or use single trigger mode in the first place, even when the signal packet is repetitive.I could not find a situation where the memory size was changed by the scope itself, other than that it’s currently not capable to utilize the full memory depth with digital channels, so the maximum is limited to 14/28Mpts (normal/interleaved) in this situation.Since it all comes down to a proper trigger condition, I also weren’t able to replicate glitches at certain timebase and/or memory depth settings. I don’t think this should come as an surprise, as the actual memory depth used for a single acquisition at e.g. 100µs/div on digital channels is just 700kPts. So with this timebase it does not matter what memory depth is configured, as long as it’s more than 700k. With digital channels enabled, the scope doesn’t support history, so in contrast to using analog channels only, we have here the rather unique situation where the scope actually uses less memory than what is set in the Acquire menu.My only explanation would be that despite all that, the configured memory depth still affects the timing somehow, maybe the trigger re-arm time. Since the trigger rate and phase relative to the input signal packets will have a huge impact on trigger stability with ambiguous trigger conditions, this could explain why some combinations appear more stable than others.

author: tautech
author_rank: Super Contributor
timestamp: July 22, 2016, 10:18:34 pm
content: Quote from: Performa01 on July 22, 2016, 09:58:47 pmNot entirely.If rebooted neither SDS2k or X would retain Digital settings.This is of some hinderance for a project that is ongoing so this has been reported too.While there maybe a work around by saving a "setup" I've yet to attempt this and IMO the scope should retain last settings......it does for analog, so this needs a fix.

author: Performa01
author_rank: Super Contributor
timestamp: July 23, 2016, 01:45:13 am
content: You're right of course - after a reboot the entire channel group is enabled again. Didn't check this, because from the original information:Quote... I just didn't think of rebooting the scope.Well, at least the scope does remember which channel groups are in use. As far as I'm concerned, even if a certain project doesn't require all 8 channels of a group, I can't be bothered to turn the unused ones off in the first place. so this is a really minor bug in my book, that I might have never noticed without the discussion here.

author: 9a4wy
author_rank: Contributor
timestamp: September 08, 2016, 12:34:47 pm
content: another one probably...If you save CH1 to reference trace, scope shows progressively saving bar, but I don't know where is the REF trace saved...If you try to recall REF trace scope is asking USB stick...Kristian

author: tautech
author_rank: Super Contributor
timestamp: September 09, 2016, 11:04:40 am
content: Quote from: 9a4wy on September 08, 2016, 12:34:47 pmI've not got a SDS2000 now only a 2kX series and it works fine in it to USB.Confusion arises because the first option in the Save type is Setup, which by default saves to internal flash unless USB is selected.On my 2kX whenReferenceis selected for save only USB is offered as the destination and it automatically asks for a USB stick to be inserted if one is not connected.QuoteYes, as above it only saves Ref waveforms to USB.Be sure to select Reference and not Setup when saving the waveform initially.

author: tautech
author_rank: Super Contributor
timestamp: November 23, 2016, 06:01:15 pm
content: New FW versions for SDS2000 and SDS2000Xhttp://www.siglentamerica.com/gjjrj.aspx?id=15Sample from changelog:1. Optimized the FFTa) The maximum number of FFT points was increased from 1.4k to 16kb) Flattop window was addedc) The UI was optimized2. Optimized the hardware frequency counter. The precision at low frequency was improved3. Optimized the Autoset function4. Optimized the efficiency on the LAN port5. Fixed some bugsa) The abnormal display of digital channels in some casesb) The IIC decoded results don’t follow the zoom changec) AC/HFR trigger brokend) UART decoding broken in previous 1.2.2.x versione) …

author: TheDefpom
author_rank: Frequent Contributor
timestamp: November 23, 2016, 08:33:03 pm
content: Thanks, I have installed the update and am just looking through it now, I see they looked at some of the issues I raised in my bug reports, good to see this happen.I can confirm that the frequency display is now almost perfect, out by 2 of least significant digit (i.e. 10.0002 KHz for a 10.0000 signal, or 10.0002MHz for a 10.0000MHz signal), still this is a LOT better than it was, making the frequency display actually usable now.I will report back on other testing as I get to it.

author: Tsippaduida
author_rank: Contributor
timestamp: May 29, 2017, 06:57:09 pm
content: I just wanted to thank you all for this rather lengthy thread.I bought SDS2104X after rather long weighing on my options for fist own oscilloscope. I ended up getting this as a) don't have enough funds to buy a "proper" scope, like Iwatsu or Keysight etc. with similar specs. b) I did look for used scopes, but here the second hand market is quite small and I did not find anything comparable (I wanted 4 channels and 100 MHz as analog bw). c) There is local representative giving excellent support, he even checks out each equipment d) Local representative means I can return the equipment for maintenance at lower cost.So far for my modest needs the oscilloscope has worked rather well. Thanks to you all, I learn immense amounts about scopes inner workings, limitations and workarounds.

author: tautech
author_rank: Super Contributor
timestamp: May 29, 2017, 08:37:27 pm
content: Welcome to the forum.Your experience looking for a scope mirrors a recent customer of mine, the SDS2000X is good value in its class.Quite possibly your supplier is also well known member here.

author: 9a4wy
author_rank: Contributor
timestamp: May 30, 2017, 09:31:42 am
content: new FW...1.2.2.2aaaaaaaaaaaaaaaaaFinally bigger letters/numbers for us, over 45, in the measure menuk

author: gman76
author_rank: Contributor
timestamp: January 03, 2021, 01:05:39 am
content: Tautech, can you provide a link to the latest FW for the SGS2000 (not SDS2000X)? I have 1.2.2.1R9.Why doesn't Siglent provide old fw versions on their website?

author: Martin72
author_rank: Super Contributor
timestamp: January 03, 2021, 01:08:47 am
content: SGS

author: gman76
author_rank: Contributor
timestamp: January 03, 2021, 01:19:07 am
content: Sorry, SDS2000. Not SGS.I see a lot of posts about 1.2.2.2 but is that for the SDS2000X?

author: Martin72
author_rank: Super Contributor
timestamp: January 03, 2021, 01:25:36 am
content: You can get FW even for the SDS1000, but SDS2000 seems to be "banned" from their site...

author: tautech
author_rank: Super Contributor
timestamp: January 03, 2021, 01:28:58 am
content: Quote from: gman76 on January 03, 2021, 01:05:39 amAFAIK 1R9 is the last version I have when I look at my FW archives. The file date is 16 April 2018.But maybe not, I see an earlier mention of 1.2.2.2 by 9a4wy however by that time I'd sold my SDS2304.I'll get it from the factory and send it to you by email so PM me with your email address. Should be able to get it with a day or two.QuoteThey did in a hidden website that seems no longer available.

author: gman76
author_rank: Contributor
timestamp: January 03, 2021, 01:36:19 am
content: I just tried 1.2.2.2R19 and the scope didnt take it, displayed "Does not Match Product Type".

author: tautech
author_rank: Super Contributor
timestamp: January 03, 2021, 01:40:18 am
content: Quote from: gman76 on January 03, 2021, 01:36:19 amCorrect.It's for SDS2000X models NOT SDS2000 !

author: gman76
author_rank: Contributor
timestamp: January 03, 2021, 01:48:55 am
content: OK, thanks. I must be misread your post on Nov 23 ..."New FW versions for SDS2000 and SDS2000X"

author: tautech
author_rank: Super Contributor
timestamp: January 03, 2021, 02:01:23 am
content: Quote from: gman76 on January 03, 2021, 01:48:55 amSorry for that and the link provided would have been for firmware for both models where you would select the firmware to match your scope.Yes damn nuisance when links no longer work. Websites have changed much over the years.

author: rf-loop
author_rank: Super Contributor
timestamp: January 03, 2021, 05:31:53 am
content: HereFW 1.2.2.2 for SDS2000Note, at this time FW files was mostly .rar not .zip as mostly today. First read all 3 pdf included in package. For update use empty, max 8G USB flash, single partition, formatted as genuine FAT32 with cluster size 4k. Update file placed to root. Overall these works best least with bit older Siglent instruments.

author: gman76
author_rank: Contributor
timestamp: January 03, 2021, 11:24:03 pm
content: rf-loop, thanks for the link but are you saying it's no longer active? Or are we supposed to fill in the xxxx blanks?

author: tautech
author_rank: Super Contributor
timestamp: January 04, 2021, 12:28:50 am
content: Quote from: gman76 on January 03, 2021, 11:24:03 pmI grabbed from rf-loops link so if you want a copy send me your email via PM and I'll shoot it through to you.

author: tautech
author_rank: Super Contributor
timestamp: January 04, 2021, 05:59:09 am
content: Quote from: tautech on January 04, 2021, 12:28:50 amPM received and email with attachment sent. Check your Inbox and/or Spam folder gman76.

author: rf-loop
author_rank: Super Contributor
timestamp: January 04, 2021, 06:46:33 am
content: Quote from: gman76 on January 03, 2021, 11:24:03 pmReply #247 There link repaired.

author: totaharry
author_rank: Newbie
timestamp: August 15, 2021, 11:49:04 pm
content: Hi, I'm Matias, I have a sds2302 and I would like to update it to v2 but all the links are offline.If any colleague can pass me the firmware I will be grateful.

author: tautech
author_rank: Super Contributor
timestamp: August 16, 2021, 05:16:32 am
content: Quote from: totaharry on August 15, 2021, 11:49:04 pmPM received and replied to.Check your inbox.

author: tv84
author_rank: Super Contributor
timestamp: August 16, 2021, 08:46:45 pm
content: Latest version.

author: tautech
author_rank: Super Contributor
timestamp: August 16, 2021, 09:48:29 pm
content: Quote from: tv84 on August 16, 2021, 08:46:45 pmChecks as same version linked by rf-loop.ADS file expands to ~7MBThe V1-V2 instructions need be followed and attached.

author: gejianyong
author_rank: Contributor
timestamp: March 12, 2023, 05:37:11 am
content: Hello, my oscilloscope model is SDS2034. I want to turn on the decoding and signal generator functions of this oscilloscope to get the correct accessory serial numberDo you have a way？

author: gejianyong
author_rank: Contributor
timestamp: March 12, 2023, 05:38:02 am
content: Hello, my oscilloscope model is SDS2034. I want to turn on the decoding and signal generator functions of this oscilloscope to get the correct accessory serial numberDo you have a way？

author: rf-loop
author_rank: Super Contributor
timestamp: March 12, 2023, 07:27:46 am
content: Just for keep care all who need update for this SDS2000 series oscilloscope to latest FW (after this version not anymore new versions).Just sidenote for @gejianyongAFAIK, in Siglent portfolio there have not been model SDS2034 (perhaps typemistake)I think you talk about SDS2304And for your question about options I have no answer. These old models are very different compared to more new SDS2000X ? ? models. Have you tried to talk nicely with Siglent Shenzhen office. Perhaps you can try because this is obsolete model and there is no anymore business with it... least I hope they can be some kind and think that if they help you ... you know that a good reputation for a company is more valuable than gold and good word spreads. Later you or some your contacts may purchase Siglent new instruments. Call and try...BTW at this time when these models was in production option keys was generated ONLY in Siglent HQ and it need Serial number AND scope IDThis is genuine last FW update package from Siglent. This time it was usual that Siglent share these packages in .RAR format. Today mostly .ZIPSDS2000-FW-V-1-2-2-2.rarFor these models only:SDS2072/SDS2074 70MHzSDS2102/SDS2104 100 MHzSDS2202/SDS2204 200 MHzSDS2302/SDS2304 300 MHzThis rar package include these files:sds2k_V100R02B01D02P02_fvA1609220922M160922.ADSSDS2000 Firmware 1.0 to 2.0 Update Instructions.pdfSDS2000 Firmware 2.0 Revision History.pdfSDS2000 Firmware Update Instructions.pdfIt is highly recommended to share always full package including all original files.ETA: If someone still have V1 generation FW version in this model.I have also this first V2 version FW package what include also .CFG file what is needed as can see in V1 to V2 update instructions)

author: tv84
author_rank: Super Contributor
timestamp: March 12, 2023, 08:56:25 am
content: Quote from: rf-loop on March 12, 2023, 07:27:46 amQuote from: gejianyong on March 12, 2023, 05:38:02 amPM me and I'll help.

author: gejianyong
author_rank: Contributor
timestamp: March 12, 2023, 09:53:01 am
content: my model is sds2304,

author: tautech
author_rank: Super Contributor
timestamp: March 12, 2023, 10:06:47 am
content: Quote from: gejianyong on March 12, 2023, 09:53:01 amSend PM to tv84 with your ScopeID from the Sys Info page.

author: gejianyong
author_rank: Contributor
timestamp: March 12, 2023, 10:34:41 am
content: My model is SDS2304. I called the head office of siglent and they replied that this model has been out of production for many years without any technical help. My previous version was 1. X. It was only after finding the upgrade file on the forum that I upgraded to the current 2. X

author: gejianyong
author_rank: Contributor
timestamp: March 12, 2023, 10:37:11 am
content: thank you

author: gejianyong
author_rank: Contributor
timestamp: March 12, 2023, 03:58:05 pm
content: Thank tv84 for his help. The AWG Decode PAS has been successfully installed, but the MSO digital channel cannot pop up a window by pressing the installation button. The digital channel interface of my machine is also missing. It may be that the hardware does not have this function, so the software cannot be installedtv84 He asked me to upload pictures for your help

author: euforia51
author_rank: Newbie
timestamp: May 01, 2024, 04:05:11 pm
content: Quote from: gejianyong on March 12, 2023, 05:37:11 amHello... first time post question. I've been following the blog for a while looking for a solution to re-enable the AWG for my SDS2104X.Same issue as above.I want to enable the AWG and other options if possible. The AWG is a priority.Following the blog, I learned my scope does not have a built in web server.And therefore, I cannot enable these options so easily, if at all.I've had the scope for several years now and did not realize when I purchased it that the AWG was on a temporary license.It was finally disabled about a month or so ago. I used it a lot and rarely turned it off.Hopefully, someone can help. I didn't want to start a new topic as I'm pretty sure this has been covered in many threads.But maybe there's a way I haven't seen yet.Thanks very much!

author: MetalHead
author_rank: Contributor
timestamp: October 18, 2024, 12:30:20 pm
content: Hello guys!my scope is SDS2102 (without X)after FW update to 1.2.2.2 the scope stuck on black screed and cannot jump to "Siglent" logo any more..Past FW ver: SDS2000-V2.0-1.02.01.28R1Upgrade to: 1.2.2.2 (last one)the upgrade process went ok, but after restart it does not load any more... ((What can be done in this situation?

author: tautech
author_rank: Super Contributor
timestamp: October 18, 2024, 02:07:09 pm
content: Quote from: MetalHead on October 18, 2024, 12:30:20 pmTry this:https://siglentna.com/operating-tip/oscilloscope-hardware-reset/

author: MetalHead
author_rank: Contributor
timestamp: October 18, 2024, 04:50:50 pm
content: Quote from: tautech on October 18, 2024, 02:07:09 pmNo, it does not help. It seems that right when it should show "Siglent" logo it gets stuck.

author: tv84
author_rank: Super Contributor
timestamp: October 19, 2024, 10:54:01 am
content: Quote from: MetalHead on October 18, 2024, 04:50:50 pmDid you followed all the instructions as they are inside the FW package of this post?https://www.eevblog.com/forum/testgear/siglent-sds2000-new-v2-firmware/msg4750610/#msg4750610

author: MetalHead
author_rank: Contributor
timestamp: October 19, 2024, 11:49:19 am
content: Yes.Initially this scope had 1.1 version. So I downloaded FW update -https://siglentna.com/USA_website_2014/Firmware&Software/firmware/SDS2000-V2.0-1.02.01.28R1.rarwhich had CFG and ADS files and updated it as per instruction from 1.0 to 2.0 versions. It went OK.Next I downloaded 1.2.2.2 firmware with only ADS file and updated FW per instuction. Everything went ok, there was message that upgrade successful please reload DPO. But after that it couldn't boot any more. I tried to reload it and press MATH button, but no way.Maybe the problem is that I went straight from 1.02.01 version to 1.2.2.2 skipping intermediate updates?

author: berik
author_rank: Newbie
timestamp: November 18, 2024, 01:21:10 pm
content: I've applied the 1.2.2.2 firmware update to a Siglent SDS2304.Let me capture what I did, hopefully it helps someone.The update process I took:Step 1: Download both theSDS2000.cfgand the1.2.2.2 firmwareStep 2: Format a USB drive as FAT32Step 3: Add the SDS2000.cfg file and the sds2k_V100R02B01D02P02_fvA1609220922M160922.ADS files to the usb driveStep 4: Unmount the usb drive and plug it into the scopeStep 5: Press the Utility button and navigate to Firmware, select the SDS2000.cfg file. Wait for the scope to rebootStep 6: Repeat step 5, but now select the firmware update file (.ADS file)After this step the scope is updated, but the help system does not work yet. I haven't tried yet, but likely the help system will work againwhen repeating step 6 (this is covered in the upgrade manual pdf).Observations:I had no problem going from a 1.1 version to 1.2.2.2 in one goI notice a degradation in performance when using on-screen measurements:Before the update, the measurements had some performance impact, but after the update it got way worse. Whena measurement is on-screen, the frame rate will drop to about 1fps or lower. I didn't measure before the update, butI recall the measurements to not be such an issue before the update. I'm considering to downgrade (if at all possible) becauseusable on-screen measurements are more important to me than the functions the 1.2.2.2 firmware unlocks.I've tried installing SDS2000X firmware, but the scope refuses to install this software.

author: berik
author_rank: Newbie
timestamp: November 20, 2024, 03:04:10 pm
content: Quote from: berik on November 18, 2024, 01:21:10 pmAfter some more testing, the fps problem went away completely. I'm not sure what caused it. On screen measurements now display and update async from the waveform, which is rendered often enough to be useful.I do have a question: What type of port is the DIGITAL input?I bet it be used with just the connector and some cables. Does anyone have experience with that?

author: tautech
author_rank: Super Contributor
timestamp: November 20, 2024, 07:26:10 pm
content: Quote from: berik on November 20, 2024, 03:04:10 pmA low voltage input into a comparator via a simple compensation network in the probe breakout.IIRC SDS2000 used a SCSI PC drive cable to the breakout head.You might find values in theSPL2016 DIY threadwill work but maybe not meet the OEM specifications.

author: berik
author_rank: Newbie
timestamp: November 20, 2024, 11:39:09 pm
content: The SPL1016 is sold out everywhere I looked.Looking at theSPL1016 internals, I'm sure I won't be able to build that.. in one weekend.First thing I found that looks to be a somewhat close match is the "Rigol MSO5000 PLA2216 Custom 16 Channel Logic Probe" clone, which can be had for only $75. I probably also need a second hand SCSI/VHDCI cable to connect it to the scope, and figure out the wiring. That seems doable. But will it work? Does someone have experience with this?And, does anyone know if theRigol RPL1116is compatible with the SDS2000 series? It looks like they use the same socket, but the chance seems low that it'll be compatible between brands like that.Are there wiring diagrams for these connectors available?

author: Performa01
author_rank: Super Contributor
timestamp: November 21, 2024, 03:34:00 am
content: One should be careful. This thread deals with the SDS2000, not the SDS2000X.SDS2000 series only had 8 logic channels and matching probes were SPL2008. Since this series is long obsolete, these probes are completely incompatible with SPL2016 and cannot be purchased anymore nowadays.SDS2000Xseries is obsolete as well but uses the current SPL2016 probe, which is now standard forallSiglent MSOs above the entry level.SPL1016 is for the bottom range SDS1000X-E, SDS2000X-E, SDS800/1000X HD models. This is a completely different concept, i.e. an independent subsystem which only provides time/trigger synchronization, hence rather poor system integration. There's also no chance to build a clone for that.

author: diegospinola
author_rank: Newbie
timestamp: April 06, 2025, 09:02:46 pm
content: Hi there tv84 , I'm trying to get the extra options for my SDS2034 that I managed to get it fixed after shipping it half way across the world during a move...unfortunately I don't think I can PM you, probably cause I'm a "new" user (used to have an account here a long time ago but I guess lurkers were removed at some point in the past 10y+) , if you feel particularly charitable maybe I can reply a DM? ThanksQuote from: tv84 on March 12, 2023, 08:56:25 am

author: Sergii
author_rank: Newbie
timestamp: October 04, 2025, 08:00:05 pm
content: Hi tv84,My oscilloscope is sds2202 (without X)I've successfully upgraded FW to 1.2.2.2Now I want to turn on the logic decoding and signal generator functions, could you help me with this?Unfortunatly I'm not able to write PM to youQuote from: tv84 on March 12, 2023, 08:56:25 am

author: TruongNguyen
author_rank: Newbie
timestamp: October 08, 2025, 01:21:11 pm
content: Hello everyone and tv84, I recently got a Siglent SDS2102. I have tried the keygen script but it keeps saying the license is invalid. Could you please help me? Thank you :'( :'(