Some Important Points to Remember when Evaluating Waveform Update Rates - Page 1
Forum section: electronics / testgear

author: marmad
author_rank: Super Contributor
timestamp: March 20, 2013, 11:14:27 pm
content: These issues came up recently in another thread, but since more and more potential oscilloscope buyers are considering (or concerned about) waveform update rates - and more and more DSOs are appearing with faster and faster specified waveform update rates (thanks to Agilent's introduction of the InfiniVision X series), it seemed that it might be worth starting a thread to mention a couple of things - and to offer an easy-to-find location for questions and possible discussion of the topic.The two points (from the other thread) which I wanted to reiterate for members new to the discussion:1) This seems rather obvious but perhaps isn't clear to some: the published maximum waveforms per second update rate is just that - a maximum - in other words, a best case scenario with a single-channel running, lowest sample size setting, no measurements or other firmware subroutines requiring overhead to run, while using one (or a few) particular timebase setting(s). This maximum rate will then drop to something lower by doing ALMOST anything - which could include something as simple as pressing a panel button to bring out a menu.Edit:I edited the following after discussions further on in the thread started by alm - dispensing with the chart and trying to just condense the pertinent information.2) When considering blind times or average glitch capture times of DSOs, one should factor in both the waveforms per second update rate and the number of horizontal divisions that the DSO displays - since both affect the acquisition time (rate * size). Given two DSOs with equivalent wfrm/s rates at the same timebase, the DSO that displays more divisions will have a larger acquisition time - and an equivalent decrease in the average time required to capture a repeating fault.

author: jpb
author_rank: Super Contributor
timestamp: March 21, 2013, 11:33:00 am
content: I worried about this when I was purchasing my oscilloscope, as it seems to be given a lot of prominence compared to things like bandwidth and number of channels which I felt were more important. I ended up buying an LeCroy WaveJet which only has an update rate of 3,600 (from the spec sheet - I've not been able to measure it yet), but it does have 350MHz bandwidth and 4 channels and was at a very reduced price as it was 6 years old (though never used - it had been sitting in stock for a long time).I'd like to gain a better understanding of the practical implications of having a refresh rate of only 3,600 (or 1,000 according to Agilents app note comparing their scope to the WaveJet but I suspect they didn't set the WaveJet to its optimal settings). To a certain extent it is a quantum thing. Unless your update rate is up at the 1,000,000 mark like the Agilent 3000X series the percentage of blind time is still very large so you're going to miss glitches anyway. (If you buy 20 lottery tickets instead of 1 you're more likely to win but it's still very unlikely that you'll do so.)In Agilents app note on glitches when testing the WaveJet (and others) they set the memory depth to give maximum sample rate which means that a lot of invisible memory points are being stored.If I was looking for glitches I'd set the memory depth to 500 to match the screen and maximise the update rate - if you see a glitch you then are aware that glitches exist and what trigger condition to set to recapture it at maximum sample rate. So in the app note at 1 microsec a division the WaveJet rate is dropped to 625 but at 1GS/s the number of samples captured per screen is 10,000 i.e. 20 screens worth. Setting it down to 500 might give something like the stated rate of 3600 - still only a tenth of Agilent's but more respectable and about 3.6% of the actual screen rate. With the blind time being 96.4% and events happening say 10 times a second over a period of 5 seconds the chances of missing the event is only about 13% so the WaveJet owner would have an 87% chance of spotting the glitch. The Agilent owner of course would do better with 35,000 or 35% his chance of missing the event is more or less zero.By the way, your scaled figures for the Rigol probably should be slightly adjusted. At present you have an update rate of ~3 at 50mS where the screen takes half a second to draw and ~6 at 20mS where the screen takes a fifth of a second to draw!

author: marmad
author_rank: Super Contributor
timestamp: March 21, 2013, 03:51:26 pm
content: Quote from: jpb on March 21, 2013, 11:33:00 amThat's true. And I suspect it probably has to do with Agilent's marketing push when they released the InfiniVision X series. OTOH, it's not a fabricated specification - and it's a feature (perhaps like anti-lock brakes on a car) which you might never even realize would have saved you a lot of trouble had you had it.Quote from: jpb on March 21, 2013, 11:33:00 amPerhaps the most sensible way to think about it is the method outlined inthis Rohde & Schwarz paper: it's really all about probabilities since we're talking about random events. Using your specifications (and R&S equations), the average test time (at the 1us scale) for your DSO to catch a repeating signal fault of 10 p/sec (to a probability of 99.9%) is ~31.98 minutes. Again - this is about probabilities - your DSO might catch the glitch in 1 minute - but to be 99.9% sure that it would see a 10 p/sec glitch, you would have to give it ~32 minutes.Looking at the chart below (from the above linked paper showing test times needed to catch a 10 p/sec glitch with a probability of 99.9%), my feeling is that, in terms of glitch-hunting, anything below 1k would probably be severely problematic; 1k - 10k would be difficult but feasible; and anything over 10k would be the most optimal.Acquisition Rate- Test Time100 wfms /s- 19 hours: 11 min : 08 s1,000 wfms /s- 1 hour: 55 min : 10 s10,000 wfms /s- 11 min : 31 s100,000 wfms /s- 1 min : 09 s1,000,000 wfms /s- 7 sQuoteHa, ha... yes, nicely spotted. I just ran the math on the old numbers while rounding - forgetting about the actual timebase scale of the screenOf course, at those slower speeds all DSOs are more or less equivalent. I'll correct that now.

author: Gunb
author_rank: Regular Contributor
timestamp: March 21, 2013, 04:24:49 pm
content: Hi,a few years ago one professional article appeared in the German magazine "elektronik industrie" and was written by Agilent engineers.It really revealed the relation between probality to see a seldom outlier and the necessary time depending on the wfm/s.Later on I've found an Agilent paper, where these details are explained well and which was the base for the article in the magazine.Attached it to this comment.I've done a few attempt last week with the DS4012 and a counter connected to the trigger output. Could reach about 105.000 wfm/sat max.RgdsGunb

author: marmad
author_rank: Super Contributor
timestamp: March 21, 2013, 04:33:10 pm
content: Hi Gunb,Quote from: Gunb on March 21, 2013, 04:24:49 pmThanks - yes, this is the paper most often quoted - and from which I took the Agilent figures listed above.Quote from: Gunb on March 21, 2013, 04:24:49 pmBTW, since your Rigol uses a 14-division screen (like mine) your normalized 10-division maximum speed (to compare it to other scopes listed in the Agilent paper) would actually be 147.000 wfrm/s (105 * 14 / 10).

author: jpb
author_rank: Super Contributor
timestamp: March 21, 2013, 04:36:34 pm
content: Quote from: marmad on March 21, 2013, 03:51:26 pmWith those times I'd say only the 1,000,000 case is feasible for manual probing. For all other cases you're going to have to leave the scope connected and go away and do something else, it then comes down to how long you leave it.I've been wondering whether ETS might be used to increase the probability of catching glitches. For example the WaveJet has a 100GS/s mode which presumably combines 100 trigger points so that each screen is an amalgam of 100 screens and since it doesn't have to display the 100 screens separately it might refresh them a lot quicker.When I eventually get myself an AWG I'll be able to experiment.

author: marmad
author_rank: Super Contributor
timestamp: March 21, 2013, 04:47:49 pm
content: Quote from: jpb on March 21, 2013, 04:36:34 pmWell, a lot hinges upon on whether you're just checking for faults - or actively trying to find one. Certainly the 1M rate is the one to have for people who's livelihood depends on seeing a potential problem right at the outset. Using infinite persistence, segmented capturing, etc. can aid the majority of us who need to locate a glitch using a 1k - 100k rate DSO within a reasonable frame of time.

author: marmad
author_rank: Super Contributor
timestamp: March 21, 2013, 04:52:46 pm
content: Quote from: jpb on March 21, 2013, 04:36:34 pmI don't think ETS would 'see' a glitch since it's not a repetitive signal - hence it couldn't be reconstructed from samples taken over many cycles.

author: Gunb
author_rank: Regular Contributor
timestamp: March 21, 2013, 04:57:23 pm
content: Quote from: jpb on March 21, 2013, 04:36:34 pmETS uses several periods of a signal to assemble a new one of them. It is a mathematical achieved higher sample rate, I would say it does not affect the wfm/s. So, the dead-time between to "screenshots" is still there, and if the glitch occurs between two subsequent screens, you won't see them either. You still will have to wait. Or am I wrong?For slower wfm/s, turn on persistency and have a coffee - the lower the wfm/s there more coffees you will drink - advantage: you can't fall asleep while staring at the screenOther question: if higher wfm/s is needed for your application at all.

author: robrenz
author_rank: Super Contributor
timestamp: March 21, 2013, 05:09:46 pm
content: Most of the instrument specification things we fret over ashobbyistswe will never use. We want the latest and greatest gear to feel good or just in case we ever build something instead of permanently building a lab preparing to build something that we have not even defined yet.But this is a good thread

author: nctnico
author_rank: Super Contributor
timestamp: March 21, 2013, 06:15:54 pm
content: I agree. The waveform update rate is only of use in the persistent mode. Now everyone raise their hand if they used persistent mode for a real measurement in the last year.

author: jpb
author_rank: Super Contributor
timestamp: March 21, 2013, 06:34:31 pm
content: My understanding of equivalent time sampling is that it takes samples at the normal sample rate (1GS/s say) and repeats this over several trigger events, but each time there is a small and random time offset.Thus the points are interleaved.If the glitch is big enough to be visible at the 1GS/s rate it will show up in some of the interleaved points even though it is missing for many of the triggers.Of course the ETS mode might be much slower anyway so any gain in merging 100 screens in one would be lost in update time.It is just an extra avenue for exploration.

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: March 21, 2013, 07:37:13 pm
content: Quote from: robrenz on March 21, 2013, 05:09:46 pmYou're probably right. Personally, I think the whole wfm/s thing is way overblown, and at the end of the day seems to become what 'GHz' numbers were in the days of the dreadful Penium4. And in my work I can catch most random small glitches with a flexible set of advanced triggers, or with large acquisition memories and a search function. Higher waveform rates are of course welcome, but at least for me it would not be a critical parameter when shopping for a work scope.I guess a very high wfm rate may be good for people that are used to analog scopes, and use a DSO like an analog scope.

author: marmad
author_rank: Super Contributor
timestamp: March 21, 2013, 07:45:50 pm
content: Quote from: nctnico on March 21, 2013, 06:15:54 pmHmm... either you're not understanding waveform update rates - or I don't understand what you're saying by this. If you use a DSO - and you use it at any horizontal timebase setting < 1ms - then you're 'dealing' with your scopes waveform update rate whether you realize it or not. Maybe instead of speaking in terms of waveform update rates we should speak in terms of blind time. Digital scopes - by their very nature - become more and more blind to the waveform data as the timebase gets smaller. Even the Agilent 3000 X-series, with it's 1M wfrm/s rate, is blind to 98% of the possible waveform at the 2ns timebase setting.

author: marmad
author_rank: Super Contributor
timestamp: March 21, 2013, 07:49:14 pm
content: Quote from: Wuerstchenhund on March 21, 2013, 07:37:13 pmPerhaps the point is that, as wfrm/s rates get higher, itallowspeople to use the DSO more like an analog scope - if that's how they'd like to use it.

author: marmad
author_rank: Super Contributor
timestamp: March 21, 2013, 08:28:13 pm
content: Quote from: robrenz on March 21, 2013, 05:09:46 pmSo you're assuming that most people in this forum either never build anything themselves or don't do any paid electronics work. Wow - I thought the exact opposite- but I could certainly be wrong.Well, I do electronics work for money (and build my own things) but honestly, most of the paid work I do is in the audio field and could be handled with a relatively low bandwidth analog scope - which I've been doing for years. But since deciding to get a low-cost DSO to add to my lab for my own work, and having tried a few of them over the last 2 years (to varying degrees of frustration), I decided to bite the bullet and spend a bit more for something with a higher update rate (and some other features I wanted).And now, after having used it for a few months - and having experienced the benefits of that - because it doesn't just mean less blind time, but it also means things like a snappier response at lower timebase settings and intensity grading of the waveform - all I can say is that I wouldneverwant to go back to a sub 1k wfrm/s DSO again. And I think most people that have used them would agree - even though we know that the vast majority of times that we use a DSO, we could make do with a slower one.

author: Gunb
author_rank: Regular Contributor
timestamp: March 21, 2013, 08:28:55 pm
content: Quote from: nctnico on March 21, 2013, 06:15:54 pmYes and no.Correct, if searching for rare events. If persistence mode is on and the glitch could be captured, the next screen will not erase the previous one and so it's visible for human eye.No if jitter should be investigated. Higher wfm/s scopes enable easier than scopes with lower wfm/s to judge how strong jitter of a signal is without persistence mode active. Had that case yesterday again where the faster Rigol revealed more details than the slower HMO. In worst case the HMO took the next screen when the jittering edge ended where it started - so the signal looked very clean. The Rigol's higher wfm/s revealed a jittering edge.

author: PA4TIM
author_rank: Super Contributor
timestamp: March 21, 2013, 08:39:23 pm
content: Chapter 5 and 6 are interesting.http://w140.com/Handbook_of_Oscilloscope_Technology.pdf( i do not know if this is part 2, just picked a link but there is an old and newer version. No commercial blah blah, just how it works. It is a bit dated, but hey, sample scopes are too, the DSO is still a baby sample scope just starting to mature a bit but they still have a long way to go f.i. on the field of signal integerity.After reading that you begin to wonder why we bother so much to make DSOs other as an easy tool every no-brainer can use. (and a huge decrease in price) despite all the disadvantages that most users will never know/experience because all they care about is digital stuff and just for that an analog (sample) scope is rather useless.But I will not discuss pros of cons of analog sample scopes, just wanted to share the link ( i have 5 anlog sample scopes and a nice DSO I like very much so I'm not anti-DSO ) and I measure only on analog and RF signals so i'm not the avarage userInteresting links in this topic.

author: marmad
author_rank: Super Contributor
timestamp: March 21, 2013, 08:54:53 pm
content: Quote from: PA4TIM on March 21, 2013, 08:39:23 pmInteresting stuff - thanks for posting this.I enjoyed reading the history part, although I had to chuckle a bit when I read the following - a clear sign of how fast technology is moving:"A modern analog scope like the Tektronix 2467 easily displays a signal 500,000 times per second, even the oldest analog scopes achieved 100,000 times. Except for the Tektronix „DPO’s“ all DSOs capture the signal only some ten to some hundred times per second, several orders of magnitude less!"

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: March 21, 2013, 09:02:36 pm
content: Quote from: marmad on March 21, 2013, 07:49:14 pmSure, and if this is what they want, why not? But these users are probably more or less the only type of users who may actually benefit from a very high wfm update rate.It's probably not of much use for users that use a DSO as what it is: a very versatile signal analyzer.

author: marmad
author_rank: Super Contributor
timestamp: March 21, 2013, 09:18:09 pm
content: Quote from: Wuerstchenhund on March 21, 2013, 09:02:36 pmYour statement doesn't make sense. How canany userfail to benefit from a DSO with less blind time? The blind time is aninherent faultof digital sampling oscilloscopes - not an attribute. That's like saying eyeglasses only benefit people who would like to read books.

author: robrenz
author_rank: Super Contributor
timestamp: March 21, 2013, 09:20:26 pm
content: Quote from: marmad on March 21, 2013, 08:28:13 pmI like good equipment and I even buy a lot of things I cant justify for any other reason than things are more enjoyable with equipment that works exceptionaly well. Do I need a JBC soldering station? No, but I don't want to solder with anything else now. Do I need a 8846A bench meter? No, but I would not give it up either. So I am with you on the nice equipment is great to work with. And thanks to Dave I have bought lots of it.I also don't mean that this thread or any thread that expounds on the fine details of understanding specifications and instrument behavior and thier impact on measurement quality are not valueable. They are actualy my favorite type of thread.My point was that myself included, it is easy (for some of us) to get caught up in focusing on outfitting the lab with the latest and greatest and stressing over which features make one instrument better or more usefull than another just because we saw a interesting video about it. When in reality we have no actual current need or experience with that piece of equipment. We just want to be prepared in case that piece of equipment is ever needed and we want an awesome lab. I think this forum is great and I am having a lot of fun getting back into electronics but it feeds this obssesive part of our human nature. I know there are many who do this for a living and these performance issues have a real impact on how easy it is for them to do thier job. But I think there are many who fit my lab builder description and there is nothing wrong with that, we all have to start somewhere.Your contribution to this forum is excellent and this thread is just another example. I didn't mean It was a waste of time to discuss this topic.

author: Unknown
author_rank: Unknown
timestamp: March 21, 2013, 09:27:38 pm
content: Quote from: marmad on March 20, 2013, 11:14:27 pmI disagree. Say we have two scopes, one 10 divs wide, the other 20 divs wide. One is set to 20 ns/div and does 50k waveforms, and the other does 50k waveforms at 10 ns/div. The blind time will be identical, but according to you the waveform update rate for the latter is higher? The first scope just compresses the same signal in less pixels, which has nothing to do with blind time.Whether slower sweep speeds (or more divs) help catching rare events depends on your signal, however. If the signal period is much longer than your sweep speed (because you need to be at the highest sweep speed to see whatever detail you were looking for in the rising edge), the extra horizontal resolution only improves the amount of detail you see per acquisition, it does not increase the number of trigger events per second. This means you're looking at less rising edges than the scope with less horizontal resolution and faster waveform update rates. You can only trade horizontal resolution for update rate if the signal period is about the same as your sweep speed.Claiming that the scope with more horizontal resolution has a faster 'true waveform update rate' is misleading, both should be stated as independent facts.

author: AndyC_772
author_rank: Super Contributor
timestamp: March 21, 2013, 09:48:03 pm
content: Quote from: robrenz on March 21, 2013, 09:20:26 pm+1The sad fact is that, in a professional context, it's the engineers who recognise and understand the need for the right, good quality equipment to get the job done - but they're not the ones who get to sign the purchase orders. That job falls to people who won't use the equipment, who don't really understand why it's necessary, and for whom it's just a capital expense that has to be weighed against the revenue which will result.It's hard to explain to someone with no electronics expertise why I wouldn't want an Atten or a Siglent anywhere near the lab, and why they should at least fork out for TTI if they won't buy me an Agilent or Tektronix. Mid-range kit should at least get the job done, though it will undoubtedly have interesting 'quirks' or 'character' which I'll discover down the line.But when it comes to my own lab, I control the purse strings - and having equipment that's a pleasure to use is a worthwhile objective in its own right. Moreover, since I work for many different customers on many different kinds of product, I never quite know what the next job will require and so it pays to be prepared. So far, every item I've picked up because I figured it might come in handy, has done.That's my excuse and I'm sticking to it

author: marmad
author_rank: Super Contributor
timestamp: March 21, 2013, 09:52:47 pm
content: Quote from: robrenz on March 21, 2013, 09:20:26 pmPoint taken - and very true. Once you use a nice piece of equipment of ANY sort (even hand tools) you don't want to go backQuoteOf course - and sorry, I wasn't implying there was anything wrong in any way with pursuing electronics as a hobby - or even with just outfitting a lab - because you might just love to own and tinker with lab equipment (I sure do). And I'm fully aware of the compulsion to overspend on gear when you might not actually need it - my weakness in that respect has been more with computer stuff than lab equipment (since I tend to do slightly more programming than electronics) - so I have certainly spent tens of thousands of dollars I didn't necessarily need to over the last few decades.

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: March 21, 2013, 09:53:29 pm
content: Quote from: marmad on March 21, 2013, 09:18:09 pmIt does, but I guess our disagreement is just because we come from different angles. If you look at a DSO simply as a modern variant of an analog scope, then you're right (for this specific situation).However, I see it a bit different (I have used analog scopes quite a lot say 20 years ago, but for more than this time my primary scopes have been digital). An analog scope is essentially a device for displaying a waveform. A DSO is much much more, and displaying a waveform is just one of the many things it can do. For my work, displaying a waveform is important, but as least as important (probably more) are the tools a good modern DSO offers to analyze the waveform. The thing is that, once you have your waveform sampled in memory, you can do all kinds of things with it that are impossible with an analog scope. This is the real strength of a DSO.Now when you say that the display blind time of DSOs is a disadvantage over an analog scope then you may be right, but when you use a DSO the same way as an analog scope then you're not really using it to its strength. I know of course that analog scopes are dead and even 'analog' users have to buy a DSO these days because that's essentially all there is, and these for these users a very high wfm rate may be important as it makes the DSO more similar to their old analog scopes. But this is not equally true for all DSO users.

author: marmad
author_rank: Super Contributor
timestamp: March 21, 2013, 10:12:01 pm
content: Quote from: Wuerstchenhund on March 21, 2013, 09:53:29 pmGranted - but to get the waveform sampled into memory requires the DSO to first 'see' it, right? If your DSO is blind to a glitch that happens in the middle of a long stream of serial data, it doesn't matter how much searching and analyzing you do of the sampled data - you won't find it because the scope never saw it.QuoteI would completely agree that theimportanceof less blind time varies from user to user - but I would only argue that, in any case, it benefits everyone - whether they're aware of it or not

author: marmad
author_rank: Super Contributor
timestamp: March 22, 2013, 12:55:18 am
content: Quote from: alm on March 21, 2013, 09:27:38 pm@Alm - your post threw me for a loop - and I had to think about what I was originally trying to get at in the opening post again.Of course, the number of divisions displayed does not affect the amount of trigger events that a DSO can respond to in a given period of time - and thus can not cause an increase in the wfrm/s rate. But what I was trying to express in the original post was the following idea:Take 2 DSOs adjusted to an equivalent timebase setting - with equivalent waveform update rates. One DSO has 10 divisions - so it's active acquisition time is 10 * the timebase. The other DSO has 14 divisions so it's active acquisition time is 14 * the timebase. All else being equal, as far as I can determine, the blind time of the second scope is ~30% less than the first. Am I wrong in this deduction?Anyway, I was attempting to 'translate' this into a wfrms/s speed (of the first DSO) which would yield the equivalent blind time. But perhaps the way that I expressed this idea was misleading and needs to be re-edited to more correctly reflect the notion of a reduction of blind time - as opposed to an increase in waveforms per second.

author: Someone
author_rank: Super Contributor
timestamp: March 22, 2013, 06:08:57 am
content: Quote from: marmad on March 22, 2013, 12:55:18 amYes, you are wrong. The 10/14 ratio applies to the recorded time, not the dead time.dead_time = 1/(update_rate) - record_lengthWhich after correcting for your erroneous 23% bonus in the originally presented waveform rates we end up calculating the Rigol has a blind time averaging a respectable 5 times longer than the competing (and more expensive) Agilent model.

author: Gunb
author_rank: Regular Contributor
timestamp: March 22, 2013, 08:23:30 am
content: Quote from: PA4TIM on March 21, 2013, 08:39:23 pmExactly, you say it all."It's digital, it must be better" - unfortunately often a wrong statement.

author: marmad
author_rank: Super Contributor
timestamp: March 22, 2013, 09:49:04 am
content: Quote from: Someone on March 22, 2013, 06:08:57 amMy original assertion that the number of divisions decreases the blind time is correct - but the percentages are wrong. As you mentioned, the percentage is theincreasein acquisition time, with a correspondingly smaller (depending on the initial ratio) decrease in blind time.Rigol's blind time percentage, with a 50,000 wfrm update rate of a 280ns acquisition time (14 divisions * 20ns), is 98.6%Agilent's blind time percentage, with a 54,000 wfrm update rate of a 200ns acquisition time (10 divisions * 20ns), is 98.9%Agilent's blind time percentage, if it had a 70,000 wfrm update rate of a 200ns acquisition time, would be 98.6% - exactly what Rigol's is at that timebase.Of course, as alm pointed out, this does not mean, for example, that the Rigol can be respond to 70k trigger events at that timebase setting - it just means, given an equivalent timebase setting and wfrm rate, that it's less blind than a 10 division scope.I will re-edit the original post to reflect this data later today.

author: Someone
author_rank: Super Contributor
timestamp: March 22, 2013, 12:44:14 pm
content: Quote from: marmad on March 22, 2013, 09:49:04 amLess blind as a percentage of time, which is important if the infrequent signal you are looking for is not correlated on the trigger, which interestingly for the Agilent model can be gotten around by switching to the slower timebases and then zooming in after the fact since the capture rate is synthetically limited. As you say the calculation is valid when the comparison is made between two scopes with the same capture rate (and also importantly memory depth and bandwidth if you want to ensure the information captured is equivalent), but you tried in the original post to then reverse the calculation and create an equivalent waveform rate for this which is slight of hand as the waveform rate is tied to the triggering. Fair enough point out that the Rigol can capture a lot more data if those waveform rates at with memory depths that are the same or larger, but it cannot be equated to a different capture rate, in that case come up with a metric which describes the captured data (say displayed (MHz*Samples)/Second) or use the established blind time expressed as a percentage.I'm not sure if the Rigol maintains the full memory depth at all horizontal settings, another of the big selling features of the Agilent when you're used to Tek (RIP, lol).

author: marmad
author_rank: Super Contributor
timestamp: March 22, 2013, 01:06:38 pm
content: Quote from: Someone on March 22, 2013, 12:44:14 pmTrue - as alm first pointed out to me. When I wrote the original post I was thinking of blind times - and trying to come up with a quick and easy way to display the difference to people used to seeing waveform update rates advertised - but I can see now how it's misleading. I'll edit it to blind time percentages or something else a bit later.

author: AndyC_772
author_rank: Super Contributor
timestamp: March 22, 2013, 01:44:56 pm
content: Quote from: marmad on March 22, 2013, 12:55:18 amYou're absolutely correct. The difference is that one waveform represents more data actually acquired and displayed on a 14 division scope as opposed to a 10 division. To pretend otherwise is to effectively say we'll ignore any useful waveform information that's captured and displayed in 4 of the divisions on the wider scope.I'm surprised the maths seems to be so confusing, because it's so easy to derive from first principles that even I can do it...In 1 second, there is a theoretical maximum of 1 second's worth of information to be captured and shown. Any measurements we make should result in a figure which is a percentage of this amount.The actual amount of information captured is the number of waveforms/sec times the amount of time each waveform represents. The amount of time each waveform represents equals the time base setting in seconds/division times the number of divisions.So, for example, my old Tektronix TDS754D manages a very creditable 185,000 waveforms/sec at 25ns/div. Not bad at all for an instrument 15 years old, IMHO. (Switch off DPO mode and it's down to just 64 waveforms/sec!)Each of those waveforms occupies 10 divisions at 25ns/div, for a total time of 250ns. Therefore, the total active time is 46.25ms per second. This makes the blind time 95.375%.

author: cyr
author_rank: Frequent Contributor
timestamp: March 22, 2013, 02:35:43 pm
content: I think a table with an adjusted *timebase* would be closer to the truth, forget about "divs" and think about the total amount of signal captured/displayed.e.g. 10ns/div on a traditional scope is 100ns/screen, but it is 140ns/screen on the rigol. If the traditional scope was set for 14ns/div (or the rigol at ~7.1ns/div) they would capture the same information on the screen and then the capture rates would be directly comparable.

author: Unknown
author_rank: Unknown
timestamp: March 22, 2013, 06:37:17 pm
content: Say I have a very rare problem where there is a spike on the power rail to my chip drops just as the /CS line of the SPI goes high (lets assume the repetition rate is high enough so the update rate of the scope is the limit). I set the scope to trigger on the rising edge of /CS, and attach the other channel to the Vcc pin. I want to witness as many /CS rising edges as possible so I don't have to wait forever to verify whether the problem is fixed. What does extra divs on my screen, or even extra sample memory, buy me? It might give me some more horizontal resolution, but this is unrelated to update rate. The power supply is not going to drop well after the /CS transition, so the extra information is useless to me.I would argue this is a fairly common case, the demo of a square wave with a single glitch in it seems artificial to me.

author: AndyC_772
author_rank: Super Contributor
timestamp: March 22, 2013, 06:43:22 pm
content: In that instance, the figure of merit would just be the number of waveforms/sec, and you'd be free to choose whatever time base setting gives you the highest rate consistent with capturing all of the event you're interested in.What you describe sounds like a fairly deterministic case, though. If A causes B, then more often than not, A always causes B.I must admit that I've struggled to think of real world cases where problems happen very infrequentlyandwhere I'd know so little about what's happening in the faulty case that I can't set up a trigger on it.Sometimes I even resort to, say, putting some debug code in an FPGA to detect when the fault has occurred and wiggle a GPIO, which I can then trigger on. It seems like a much more predictable way to ensure I see what's happening in the interesting case.

author: marmad
author_rank: Super Contributor
timestamp: March 22, 2013, 07:29:25 pm
content: Quote from: alm on March 22, 2013, 06:37:17 pmIt buys you exactly as formulated above - less blind time. Simple as that. Whether that's of any use to you in whatever ways you use a DSO, I couldn't say. But that's what you get with extra divs.

author: Galaxyrise
author_rank: Frequent Contributor
timestamp: March 22, 2013, 09:02:21 pm
content: Quote from: alm on March 22, 2013, 06:37:17 pmI think the point is that you're not limited by update rate, you're limited by blind time. Converting from wfm/s to blind time involves knowing how much time is represented by one waveform, which is a combination of s/division and divisions/waveform.A 'division' is just an arbitrary amount of the screen, anyway. Any scope with same number of pixels can potentially show the same detail if you can fine adjust the time base. But number of divisions does come up in the math, even if it's not "buying" you anything.

author: Rufus
author_rank: Super Contributor
timestamp: March 22, 2013, 09:38:29 pm
content: Quote from: nctnico on March 21, 2013, 06:15:54 pmThe whole point of Tektronix DPO and other implementations is to emulate the persistence of phosphor so the display gives more insight into the nature of a signal like analog scopes do. Such scopes are always in 'persistent mode' and the higher the update rate the better.

author: Someone
author_rank: Super Contributor
timestamp: March 22, 2013, 10:39:41 pm
content: Quote from: AndyC_772 on March 22, 2013, 01:44:56 pmArgh, the 30% reduction is not in the blind time! Its still wrong. If they have the same capture rate, sample rate, bandwidth, and time per horizontal division, then you could say there is a 40% increase in the captured data for a scope with 14 vs 10 divisions, but this is in no way a 30% reduction of blind time whether expressed as unit measures or a percentage of realtime.

author: Gunb
author_rank: Regular Contributor
timestamp: March 22, 2013, 11:11:11 pm
content: Quote from: Galaxyrise on March 22, 2013, 09:02:21 pmOf course they do.scope A: 12DIV * 500ns/DIV = 6µsscope B: 14DIV * 500ns/DIV = 7µs -> shows 1µs more of the signal per screensamedead timefor both now, then againscope A: 12DIV * 500ns/DIV = 6µsscope B: 14DIV * 500ns/DIV = 7µsrepeated for 1 second in total now and assumed 100.000 wfm/s then scope B shows always one 1µs per wfm extra, that is 100.000 wfm/s * 1µs = 0.1s in total more than scope A.So, each scope for itself has got 100.000 wfm/s ,but for comparison the extra DIVsof scope B have to be taken into account -> what marmad has explained well.It has nothing to do with samples in sample memory and the no. of them , that are moved to diplay buffer to be displayed depending on the limited no. of pixels of the screen. This is something quite different.I recommend to study my attachement from Agilent above, you're changing a few things.

author: Galaxyrise
author_rank: Frequent Contributor
timestamp: March 22, 2013, 11:23:09 pm
content: Quote from: Gunb on March 22, 2013, 11:11:11 pmYou left out the part where I said to adjust the time base of scope A so it also displays 7µs. Otherwise, you're saying the same thing I was: it's the s/wfm that's important, not the number of divisions the scope displays it with.QuoteI'm not sure your algebra works.. If the two scopes in your example have the same blind time, then I figure Scope A will have higher wfm/s. If scope B has a wfm/s of 100k, then its dead time is 3µs per waveform. Scope A will thus have a wfm/s of 111k (1/9µs), ya?

author: marmad
author_rank: Super Contributor
timestamp: March 22, 2013, 11:28:05 pm
content: Quote from: Someone on March 22, 2013, 10:39:41 pmYes, sorry, but it is (well, actually 28.6% - I rounded up in that post). It seems odd that we're disputing this since it's so easy to prove with math.Whoops - I was wrong - Someone is right. it would only be an equivalent reduction in blind time if the two (acquisition time / blind time) started out equal.As far as the Agilent/Rigol comparison that I mentioned in the opening post - it is ablind-timeacquisition-timedifference of 23% (for the 20ns timebase setting- in this case not fully 28% because the Agilent has a 54k wfrm/s rate vs 50k for the Rigol so they are not precisely equal). It's very easy to verify - just do the math from the Rohde & Schwarz or Agilent papers:To capture a 1 p/s glitch at the 20ns timebase setting (with a probability of 99.9%), the average time for the Agilent is 10 minutes, 40 seconds.To capture a 1 p/s glitch at the 20ns timebase setting (with a probability of 99.9%), the average time for the Rigol is 8 minutes, 13 seconds.That's a difference of 23% - and it corresponds to 54k / 70k.But for these two scopes, this figure isonly for the 20ns timebase setting- and only because the waveform update rates are very close to each other. For other timebase settings where the Agilent is way ahead of the Rigol in wfrm/s, the percentage would obviously be in Agilent's favor.

author: Someone
author_rank: Super Contributor
timestamp: March 23, 2013, 12:54:37 am
content: Quote from: marmad on March 22, 2013, 11:28:05 pmThe width of the glitch is not what determines the probability of capturing it in a certain time, its the rate at which the glitch occurs which you use to determine the time it will take to capture. Also only if the glitch is not correlated to the trigger do you get the benefit of the increased capture.Quote from: marmad on March 22, 2013, 11:28:05 pmYes, thats a difference of 23% in the time taken to capture a glitch that isnt correlated to the trigger. Not a 23% difference in the dead time as you keep claiming.Do we need to get shouty yet?

author: Galaxyrise
author_rank: Frequent Contributor
timestamp: March 23, 2013, 01:20:23 am
content: Quote from: Someone on March 23, 2013, 12:54:37 amWhat do you think is the difference in dead time?

author: onlooker
author_rank: Frequent Contributor
timestamp: March 23, 2013, 01:23:50 am
content: QuoteThe problem is that not every other respect can be equal in your example. For example, if both cases have the same number of samples per waveform and scope#1's horizontal time scale of the screen equals to the time span of all samples, the scope#2 has only half of the samples "showing". Therefore this can be regarded as "unfair" comparison since half of the samples for scope#2 are thrown away and counted towards dead time.The more "fair" comparison is to have scope#2 double the timebase, so both scopes have the same horizontal time spans on the screen (so to cover the same numbers of samples). This is same as others had argued that timebase is just an artifact except scope makers discretized it in their own particular ways.Using this "fair" comparison (with every other respect equal ) , the dead times for both scopes are the same.

author: marmad
author_rank: Super Contributor
timestamp: March 23, 2013, 01:30:20 am
content: Quote from: onlooker on March 23, 2013, 01:23:50 amThis is nonsense. I'm talking about a calculation of blind time - it has nothing to do with samples. It is not a 'fair or 'unfair' process - it's math. The calculation of a DSOs blind time requires the timebase setting, the number of divisions, and the speed of the waveform capture - with those three variables you can solve either Agilent's or Rohde & Schwarz's blind-time equation. Read the literature.

author: marmad
author_rank: Super Contributor
timestamp: March 23, 2013, 01:40:13 am
content: Quote from: onlooker on March 23, 2013, 01:23:50 amBTW, I don't think you quite understand how DSOs work if you think they accomplish decimation by first capturing samples and then throwing them away.

author: onlooker
author_rank: Frequent Contributor
timestamp: March 23, 2013, 01:49:56 am
content: QuoteI guess correct math also needs to be applied correctly to make sense.1). The correct time scale that need to be the same should be the full screen time span, instead of the timebase.2). We are talking about hunting glitches, Right? Assuming scope#2 was on 40ns timebase and everything else being equal (waveform rates, sample rates, total number of samples, softwares that processes the samples and show the glitches...), can you explain as to why scope#2 has less probability to see the glitches than scope#1?3). Again, timebase is a artifact. For a 10 divs screen, I can place my own mask that has 20 divs and rename all the timebase number by half of the original ones. That way I just turned your scope#2 into scope#1 (assuming every other aspect the same). Right?

author: nctnico
author_rank: Super Contributor
timestamp: March 23, 2013, 02:03:19 am
content: Quote from: marmad on March 21, 2013, 07:45:50 pmI understand very well. Unless you use the persistent mode you are only interested in what the scope triggers on and in that case it will show a trace from one acquisition (*). Actually you don't want many acquisition results added into one trace; the noise will be excessive. Another limit is the refresh rate of the screen and the maximum rate your eyes can keep up with.(*) Some Tektronix DSOs with a monochrome screen like the TDS200 and some TDS500 will show the previous acquisition in grey which is a handy feeature.

author: marmad
author_rank: Super Contributor
timestamp: March 23, 2013, 02:09:08 am
content: Quote from: onlooker on March 23, 2013, 01:49:56 amSure. As I mentioned, the calculation involves three variables - although two of them can just thought of as a single one: the active acquisition time - which is the timebase setting * the number of divisions. And the other variable is the frequency - the waveform update rate - the number of times that the DSO captures and displays that window of time (the active acquisition time) in a second. If you double either of those two variables - the window size that you're capturing - or the frequency that you're capturing it at, it stands to reason that you double the amount of time you're capturing in a second - thus doubling the probability of seeing a random event.

author: marmad
author_rank: Super Contributor
timestamp: March 23, 2013, 02:20:55 am
content: Quote from: nctnico on March 23, 2013, 02:03:19 amAs mentioned by someone else responding to your post, fast update scopes like the Agilent X series, Rigol UltraVision, etc. have persistence on virtually all of the time - using a gradient of the display color to indicate intensity - almost exactly like phosphor in a CRT. These DPO/VPOs are not limited by refresh rates of the screen because they basically 'stack' the collected waveforms in a Z-buffer before display. The result is that you can see tiny flickering glitches, jitter error, etc. that would be invisible on slow waveform update scopes because of the blind time. Having less blind time does not mean you have more noise - it means you see more detail.

author: marmad
author_rank: Super Contributor
timestamp: March 23, 2013, 02:26:32 am
content: Quote from: onlooker on March 23, 2013, 01:49:56 amHuh? No - a DSO has an active acquisition time - the timebase setting * the number of divisions. The only way to change this time is to change the timebase setting - you can't alter the number of divisions it collects. And changing this timebase setting, on most DSOs, also changes the frequency at which it captures the waveform. We're talking about REAL time here - not an artifact. How can you magically change 1us to 1ns?

author: Someone
author_rank: Super Contributor
timestamp: March 23, 2013, 02:35:53 am
content: Ok, we have a reference for the 50k/s acquisitions on the Rigol topping out at 20ns per division:Setting the memory to 14k was needed to achieve close to the banner acquisition rate according to that reviewer, what was the sample rate achieved?Quote from: marmad on March 23, 2013, 01:25:01 amWe return to the original post of mine stating the dead time as measure in units of time:dead_time = 1/(update_rate) - record_lengthYou provided the quote to the dead time expressed as a percentage of realtime:%dead_time = 100 x (1 – (update_rate * record_time))These are consistent with the terminology used in both the Rhode & Schwartz and Agilent documents on the topic.So lets compare these for the two scopes at your magic number of 20ns1s/54,000 - 20ns * 10 = 18319 ns1s/50,000 - 20ns * 14 = 19720 nsthe dead times are within 10%How about calculating the dead time as a percentage of realtime100 x (1 - (54,000 * 20ns * 10)) = 98.92%100 X (1 - (50,000 * 20ns * 14)) = 98.6%expressed as a percentage of realtime they are .32% differentQuoting differences in test time is completely different. Welcome to engineering, terminology is both terse and precise.

author: Someone
author_rank: Super Contributor
timestamp: March 23, 2013, 02:59:52 am
content: Quote from: Galaxyrise on March 22, 2013, 09:02:21 pmWell we can take it to silly extremes in terms of displayed data, the optimal point with the Agilent 2000 X seems to be 10us/division which would fill the 100,000 point memory neatly across the screen at the lower 1GS/s non interleaved rate. The dead time while capturing as fast as the scope can measure? apparently 10% of realtime.I dont have the details on the rigol to make a similar comparison, it would be interesting to know where its true peak of recorded information is since this thread is highlighting that waveforms/second while relevant to many measurements is not the single specification relevant when hunting glitches.

author: Gunb
author_rank: Regular Contributor
timestamp: March 23, 2013, 08:39:54 am
content: Quote from: Galaxyrise on March 22, 2013, 11:23:09 pmYou're right, but when I fine tune the RIGOL I can measure, that wfm/s changes, too. So, do we have same wfm/s on both scopes if we follow you're assumption? If not, the comparison becomes again an inaccurate thing.So, to become independent from that I've assumed that both scopes are identical with same 500ns/DIV, same wfm/s except the no. of DIV. More a theoretical approach then.Quote from: Galaxyrise on March 22, 2013, 11:23:09 pmNo, sorry, write error, was really late when I came home from work yesterday.I've meant same wfm/s, not dead time. In this case I come to the following:scope A: 6µs per wfm, 4µs dead-timescope B: 7µs per wfm, 3µs dead-time1/10µs = 100.000 wfm/sleads on both tophysical100.000wfm/s, but scope B shows more of the signal. A random event, whatever, that falls into this extra 1µs earlier than elsewhere in the signal appears earlier on screen, so I come to the conclusion, that the"weighted"wfm/s on scope B is higher. Correct me if I'm wrong.In the end this wfm/s discussions are not that important to me, as long as the scope has enough for my needs, I'm happy. My HMO has "only" up to 2500 wfm/s and up to know I could use it for everything even if my RIGOL reveals jitter much better.Have a nice weekend

author: jpb
author_rank: Super Contributor
timestamp: March 23, 2013, 11:27:35 am
content: What I would find useful would be, rather than more technical details, a poll or survey of people's practical experience.The questions would be along the lines:In the last year my high refresh rate DSO allowed me to spot glitches that otherwise I would have missed on0? 1-5? > 5? occasions.In the last year my low refresh rate DSO meant that I missed glitches and ended up wasting time/losing my job/retiring from electronics on0? 1-5? > 5? occasions.The problem is trying to value a feature against other features where you have to make a choice. In my case I had a choice between a new 70MHz Agilent DSX2000 series scope(4 channels) with high refresh but only 100k of memory and a old stock (very old 2006 vintage but never sold) LeCroy WaveJet 334 with low refresh of 3,600 but with a bandwidth of 350MHz and500k of memory for over £100 less money.I went with the WaveJet but I'm curious as to how much of a disadvantage the lower fps is given that if you're looking for a glitch you can trigger off narrow pulses, spikes, missing pulses and so on so the circumstances where 50,000 fps is good enough and 3,600 isn't I suspect is a pretty rare occurrence but I don't have much practical experience and am genuinely interested in knowning others experience. (I know we all tend to defend what ever scope we've decided to buy so it is difficult to get an objective assessment of any feature.)

author: Someone
author_rank: Super Contributor
timestamp: March 23, 2013, 11:42:58 am
content: Quote from: jpb on March 23, 2013, 11:27:35 amThe Lecroy Wavejet models are often considered closer to the next band of scopes ie comparable to the Agilent and Tek 3000 series, you got yourself a huge bargain.The practical difference between 3,600 and 50,000 captures per second is close to zero until you get that odd occasion with a high repetition signal (you cant get the captures if you arent even triggering that often). It adds some detail when looking at edges of digital logic and other high repetition signals but with clever use of the advanced hardware triggering in these mid range scopes you can get away without it, especially since the wavejet can use all that extra memory with its own take on segmented memory included as standard.

author: AndyC_772
author_rank: Super Contributor
timestamp: March 23, 2013, 11:47:24 am
content: I'm not aware of having missed things because of a limited waveform update rate, though the higher update rate I get on my Tek with DPO mode switched on does give a much better impression of what a non-repetitive waveform is actually doing. With a low update rate, such a signal (say, a microprocessor's chip select) can appear to be behaving quite randomly, while a faster update rate can reveal behaviour which is actually more predictable and deterministic.It's the proper intensity graded display that makes all the difference. Without it, the image on the screen tells you what happened the last time the scope did a sweep, and nothing else. With it, the image tells you how often things are happening, and that's much more revealing. I suspect there's some minimum number of waveforms/sec that a scope needs to achieve for this effect to really become useful.It's worth adding that I have most definitely missed things due to lack of scope bandwidth. Given the choice I'd go for higher bandwidth over higher waveform rate; it's better to have fewer sharp, detailed images of what your signal is doing than it is to have more blurry ones.

author: jpb
author_rank: Super Contributor
timestamp: March 23, 2013, 12:04:46 pm
content: Quote from: AndyC_772 on March 23, 2013, 11:47:24 amThat was my gut feel, that high bandwidth/fast rise time would be more generally useful than higher fps and a more modern design.It is interesting though, this engineer :http://www.embeddedrelated.com/showarticle/117.phpplaces much more emphasis on having a high resolution mode than having higher bandwidth. In fact he is downgrading from 1GHz to 200MHz because hefound his fellow engineers kept borrowing his 1GHz scope!Quote from: Someone on March 23, 2013, 11:42:58 amYes, I thought it was a good bargain - though I was a bit disappointed when it arrived to find it was built in September 2006 and was the old pre-A series so doesn't have control via the rear USB.But as the price I paid was roughly the same as the new list price of the 4 500MHz probes that came with it, I decided not to send it back.

author: marmad
author_rank: Super Contributor
timestamp: March 23, 2013, 12:08:16 pm
content: @Someone - sorry, I stand corrected - this proves I should never answer posts after midnight - especially ones involving math.I kept conflating acquisition time with blind time in my head - and I also realized that I had been thinking and referring in terms of blind times per second - while you have been referring to it per cycle. Anyway, with some sleep and coffee, it's obvious that a percentage increase in acquisition time could only cause an identical decrease in blind time if the two were identical to begin with (50/50 - which they hardly ever are), but it does cause an identical decrease in the average time in seconds to find a glitch.So, given the Agilent/Rigol 20ns example: at that timebase setting:Rigol acquisition time p/s: 50000 * 20 * 14 = 14msAgilent acquisition time p/s = 54000 * 20 * 10 = 10.8msA 23% difference which leads to the 23% less average time to capture a glitch (as mentioned in the previous post).Once again, sorry for my obliviousness - no more late night posting!BTW, when you posted that video in your previous post did you realize thatIwas the reviewer - or was it just a meta-joke?

author: marmad
author_rank: Super Contributor
timestamp: March 23, 2013, 01:12:19 pm
content: Quote from: AndyC_772 on March 23, 2013, 11:47:24 amAgreed. You should be getting the bandwidth you need for your work, preferably with a wfrm/s update rate >1k if you can.Quote from: jpb on March 23, 2013, 11:27:35 amThis would be difficult to ever know since it's about probabilities. You could just be 'lucky' with a lower wfrm/s DSO and manage to capture a glitch in 5 seconds - whichmighthave taken someone 'unlucky' 10 hours to find - leading to the loss of their job and retirement from electronicsSeriously though, it's just something that's nice to have - and helpful in some specific circumstances - but the vast majority of DSO work can be performed just fine without it (as people have manged to do for years).And as Someone pointed out, above a certain point, it's just gravy. Having used a few of the lower end DSOs, it seems to me that the effect and usefulness decreases as the wfrm/s rate increases. The most marked difference seems to be from < 100 to 1k, then a bit less so from >1k to 10k, then even less so from >10k to 100k, etc.

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: March 23, 2013, 01:29:28 pm
content: Quote from: jpb on March 23, 2013, 11:27:35 amI fully agree.QuoteAt least in my case I can reply to both questions with '0'.QuoteExactly. And at the end of the day, it's not that high wfm rates would have helped me to solve a problem that I otherwise couldn't. That's why it's very low on my prioritzy list for a scope. Even if I don't see a glitch in real-time on the display, it's still recorded by the scope, and I can look at it and analyze it as I see fit. A high wfm rate would certainly be nice, but at least for me the lack of it is not a deal breaker. A lower bandwidth for example would be in most cases.But one thing I should mention is that most of my work equipment is mid to upper high end (which comes with adequate wfm rates), so I'm not talking about a 25 year old CRT DSO which, if forced, shows 2 or 3 waveforms a second (in which case the low wfm rate would most certainly be a real problem). But these days even entry level scopes should have reasonable screen update rates.QuoteLook at it this way: with your WaveJet, the lower wfm rate could mean you would miss (i.e. not see) a small glitch in a signal. However, the glitch will probably be still be in your scope's memory, and (not knowing the capabilities of the WaveJet range!), so you should still be able to look at it. On the other side the very high wfm rate of the DSO-2000X is useless if you miss signal elements due to the more limited bandwith.Another thing to keep in mind (and which everyone seems to be ignoring) is that the wfm update rate does not necessarily mean that this is the rate that is actually shown on the LED screen. Its merely the limit the display controller and the processing can handle. TFT LEDs have their own limit in their pixel response times (which depending on the panel and lots of other factors is roughly in the regions of 1ms to say 25ms, and scopes rarely use the latest and most expensive panels). The response time also depends on the current and new pixel state (i.e. grey to grey, black to white). What this means is that even if your display controller can produce 1,000,000 wfm/s, the display will still only refresh at 50, 60, 100 or maybe 120Hz, but that's about it. So even if you pay for the high wfm rates it doesn't mean you are actually able to see that tiny rare glitch any better than on a scope with a lower wfm update rate.

author: marmad
author_rank: Super Contributor
timestamp: March 23, 2013, 01:46:50 pm
content: Quote from: Someone on March 23, 2013, 02:35:53 am2GSa/s. Sample size is adjustable on the Rigol - sample rate is not. And at the maximum rate of 2GSa/s of the Agilent X2000 or Rigol DS2000 series, the DSO is capturing 2Sa/ns. So at a 20ns timebase setting, you are seeing 400 samples stretched over 640 pixels on the Agilent display and 560 samples stretched over 700 pixels on the Rigol.

author: marmad
author_rank: Super Contributor
timestamp: March 23, 2013, 01:53:34 pm
content: Quote from: Wuerstchenhund on March 23, 2013, 01:29:28 pmYou've written this before in a previous post, but I don't understand your logic. Blind is blind - the scope doesnotrecord data when it's blind. If you don't see a glitch in real time, then the scope didn't capture it. Except, of course, if you mean you are just using it in single-shot mode - or you happened to look away from the scope when a single glitch happened

author: marmad
author_rank: Super Contributor
timestamp: March 23, 2013, 02:02:24 pm
content: Quote from: Wuerstchenhund on March 23, 2013, 01:29:28 pmYou are not understanding how DPO/VPO technology works. It's not hindered by refresh rates or response times of the display (at least, not up to a limit - see below) - it uses the equivalent of a Z-buffer to 'stack' waveforms for intensity grading. Each time the display is refreshed, it is refreshed with a composite image of the intensity from many, many waveforms.Edit:@Wuerstchenhund - OTOH, you're correct in the sense that there must be a theoretical limit to the amount of data which can be presented and perceived by the human eye in a second by DPOs. I don't know how to calculate that limit, but perhaps it is something like levels of intensity * refresh rate of the display? Anybody know? But it's certainly at least a 100x greater than the refresh rate.Ahhh... so I start to understand your logic from the previous post. You think that the refresh rate of the display has to do with the wfrm/s rate and the blind time. But that's not the case; the things are unrelated - except perhaps in low update rate DSOs. Perhaps we mean different things by 'not seeing'. My definition is that when the user doesn't see something, he's just missed it - but it still exists. When the DSO doesn't see something, it doesn't exist.

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: March 23, 2013, 03:07:27 pm
content: Quote from: marmad on March 23, 2013, 02:02:24 pmI'm sure I do quite well understand how DPO works, thanks.QuoteI'm sorry but you still don't understand. I never said the wfm update rate has anything to do with the screen refresh rate, and I thought that should be pretty clear from my posting.The point I am making is exactly that, wfm rate isNOTthe same as screen refresh rate. Therefore the idea that a scope with a very high wfm rate lets you see details a scope with a lower wfm update rate is simply not true in this generality (which is the main argument about why some consider a very high wfm rate to be the next best thing since sliced bread). With a DSO, as long as the glitch is in the sample memory, and as long as the other parameters (analog bandwidth, sample rate) are adequate, I will be able to look at that glitch, period. You won't necessarily be able to look at it in real-time, because especially on a scope with LCD screen you're still limited by the screen update rate. But I will be able to find that glitch, and I will be able to analyze it, no matter if the wfm rate is 1,000,000 or 100.You really should read more careful before replying.And I'm sorry to say but it also shows that your thinking is very well stuck in the days of analog scopes. Sure you can use persistence mode (no matter if monochrome or color-graded, which is what Tek sold under the 'DPO' name) to find sporadic glitches, and I agree that for this a very high wfm rate of the display controller may be advantageous, and persistence mode may very well be your only option if you use an entry-level scope e which does not offer much else, but with a decent DSO there are much better tools available to find and analyze signal deviations. The only time I use persistence mode is when I want to produce some colourful pictures showing some signal jitter for trainees, but that's about it.I do understand that for someone who comes from an analog scope, persistence mode is the obvious thing as that is essentially all that was available with an analog scope, but this is one of the reason why I don't agree with the common recommendation that it's best for EE beginners to start with an analog scope. But that's just my own opinion.

author: marmad
author_rank: Super Contributor
timestamp: March 23, 2013, 03:29:11 pm
content: Quote from: Wuerstchenhund on March 23, 2013, 03:07:27 pmWell, I'm sorry if I made a mistake, but the following sentences of yours made it sound as if you didn't:Quote from: Wuerstchenhund on March 23, 2013, 01:29:28 pm...since the display controller isnotconnected to the waveform update rate - or it's limits.QuoteAnd that is the crux of the issue, no? Finding glitches - and then getting them into sample memory - or do you just mean glitches that end up randomly in sample memory?

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: March 23, 2013, 03:46:23 pm
content: Quote from: marmad on March 23, 2013, 03:29:11 pmSure it does. The whole processing architecture affects the wfm rate. You should have a look at some DSO hardware designs.QuoteWhy do I get the increasingly strong feeling that you don't really understand how a DSO actually works?I mean this is really basic stuff.

author: marmad
author_rank: Super Contributor
timestamp: March 23, 2013, 03:58:52 pm
content: Quote from: Wuerstchenhund on March 23, 2013, 03:46:23 pmThe wfrm/s rate is the inverse of the DSO's acquisition cycle. Perhaps this is just a problem with semantics? Certainly you don't mean that the display controller IC affects the acquisition cycle?Quote from: Wuerstchenhund on March 23, 2013, 03:07:27 pmCould you elaborate on the better tools available for finding (or seeing) unknown glitches? I'm being serious - it's true that I'm reasonably new to DSOs - although I do think I understand how they work

author: onlooker
author_rank: Frequent Contributor
timestamp: March 23, 2013, 04:14:33 pm
content: I think you two are with different pre-assumptions about glitch hunting: one assumed the glitch can be triggered on; while the other assumed triggering on the glitch can not be reliabally done.

author: marmad
author_rank: Super Contributor
timestamp: March 23, 2013, 04:30:16 pm
content: Quote from: onlooker on March 23, 2013, 04:14:33 pmMaybe so. All of the time I'm discussing the wfrm/s rate (and blind times), I'm speaking about it purely as a tool that might help you notice a problem (glitch, jitter, etc) - which can then be captured and analyzed by the DSO. I realize that it is irrelevant in much of the normal usage of the DSO.

author: jpb
author_rank: Super Contributor
timestamp: March 23, 2013, 10:47:05 pm
content: I've just read an application note on Random Interleaved Sampling and this refers to a component of the DSO called the Time to Digital Converter (TDC).The TDC is used to place the trigger point very accurately between the actual samples (so that on multiple triggers you don't introduce a jitter equal to the sample rate).The reason that I'm raising this in this thread is it suddenly struck me that the TDC will place an upper limit on the waveform update rate.The TDC works by charging up from the start of the trigger to the next sample point, which will be a very short time - the maximum will be the sample to sample time whichin the app note is a maximum of 100 psecs for a 10GS/s scope.The TDC then discharges over a much longer time which is measured digitally using a clock, 100MHz in the app note. The discharge time in the app note is a maximum of5 microseconds - so 100 psecs to charge and 5 microseconds to discharge. This allows the time to be set to less than a picosecond (in the app note example).The thing that struck me was that this very long discharge time will mean that in the example given the next waveform cannot be displayed for 5 microseconds sothe waveform update rate will be limited to 200,000. OK that is quite a high upper limit but it is only 1/5 of Agilent's 3000X series. Also at slower sample rates thecharging time and thus discharging time would correspondingly increase.I suppose it is possible to store and work on triggers and sample sets in parallel but this is added complication that most manufacturers wouldn't do.It might also be that there is a trade off between wfps and timing accuracy.

author: marmad
author_rank: Super Contributor
timestamp: March 23, 2013, 11:56:14 pm
content: Quote from: jpb on March 23, 2013, 10:47:05 pmInteresting. I wonder if the InfiniiVision X series use a digital trigger - I did a quick Googling but couldn't find a definitive answer - but I would guess they probably do. I know the Rigol UltraVision line does. According tothis Rohde & Schwarz paper, one of the advantages of their digital trigger is "No Masking of Trigger Event":"An analog trigger requires some time after a trigger decision to rearm the trigger circuitry before they can trigger again. During this rearm time, the oscilloscopes cannot respond to new trigger events - trigger events occurring during the rearm time are masked.In contrast the digital trigger system of the R&S RTO oscilloscopes can evaluate individual trigger events with the Time-to-Digital-Converters (TDC) within 400 ps intervals (Figure 12) with a resolution of 250 fs."A 400ps interval would put the limit of trigger events at 2.5 meg.

author: marmad
author_rank: Super Contributor
timestamp: March 24, 2013, 12:35:36 am
content: I can understand the advantage of DSOs with faster acquisition cycles being able to trigger in shorter times - but I'm also curious about what the practical limits are for the amount of visual data that can be conveyed by these DSOs (with high waveform update rates) to the display. I haven't been able to locate any oscilloscope-specific information, although I suspect one or more manufacturers have studied it.I'm also curious why the Agilent X series only uses 64 levels of intensity gradation - it seems like a limiting factor in terms of getting information to the display. Perhaps it has to do with optimizing memory usage?

author: robrenz
author_rank: Super Contributor
timestamp: March 24, 2013, 01:16:14 am
content: IMO 64 levels from off to full brightness sounds like a lot to me. I would guess that our eye has a hard time discerning a 1/64 incremental brightness change.

author: marmad
author_rank: Super Contributor
timestamp: March 24, 2013, 01:31:20 am
content: Quote from: robrenz on March 24, 2013, 01:16:14 amI'm not so sure about that. I seem to recall that early monochrome displays had <= 64 levels of brightness - and it was slowly increased over time as a result of the non-smooth transition between gradations. But I can't really remember the details - perhaps I need to do some research.Edit:A quick scan of literature seems to present varying information - but there seems to be some consistency to the data that the naked eye is sensitive up to 1% of intensity.

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: March 24, 2013, 09:09:09 am
content: Quote from: marmad on March 23, 2013, 03:58:52 pmYes, it does (on most modern DSOs). The wfm rate is essentially the speed the DSOs processing element reads out the acquisition memory. You can see this when using lots of additional processing as the wfm rate goes down somewhat on most scopes.The image you brought up looks like it's a very old marketing drawing from Tek's first DPO scopes (which came up around a decade ago) and is not necessarily adequate for modern DSOs.Quote from: Wuerstchenhund on March 23, 2013, 03:07:27 pmFor example, if I want to find out if there are non-conformities (i.e. glitches, jitter) in a signal, I just set a mask and the allowed deviation and then set the scope to trigger on non-conformities. This works for repetitive and non-repetitive signals (i.e. a serial data bus). That means if there's a glitch then I'll see it. I can also segment the 1Gpts memory the scope has and capture multiple occurrences. Then depending on what the non-conformity is, I can run a series of analysing tools (i.e. jitter analysis, mathematical analysis) to quantify the problem, which makes it much easier to find what's causing it.As I already said in this thread, I understand that for someone coming from an analog scope, a DSO is primarily a device tolookat signals. However, for me it is (and always has been) a signal analyzer, a tool to examine and quantify signals. The fact that it has a screen just makes things easier. I am aware that you can't do that with an entry level (and even most lower midrange) DSOs, and all the high-end stuff at work does it because the company invested in most of the available options. But quite frankly, instead of this race for extreme wfm numbers that seems to start now thanks to Agilent, I'd rather see better signal analyis tools in a scope than a high wfm rate.But YMMV of course, and I'm not the typical entry level scope customer (even for home use I'd rather buy older upper midrange/lower highend stuff than new entry level; funny enough, many of the analyis tools that are in my expensive work scopes I have now at home through the old LeCroy Waverunner I bought) so it's probably just me being awkward.

author: Gunb
author_rank: Regular Contributor
timestamp: March 24, 2013, 09:31:08 am
content: Hi marmad,independent from all the other things discussed here, could not follow any comment (seems, my personal update rate is too low),did you notice which requirements RIGOL has noted in their technical specs at the end of the manual?For the DS4000 types they've required a sine of 10MHz, setting the scope to 10ns/DIV ...Just for fun I've set up the generator & scope according to that data and noticed first, that wfm/s was about 80.000wfm/s. Then I'venoticed that they required to switch off interpolation, i.e. using "dots mode" for the display - result: the counter jumped to 115.000 wfm/s.Logical that the drawing of connections between the samples may slow down the wfm/s, but didn't think about it before. So if maximum wfm/sis required makes sense to switch off interpolation. Would say, that then the higher sample rate of 4GS/s makes sense also for a scope of 100MHzbandwidth. There's not really more information, but you get more samples and the trace looks more continuously even with interpolation offas with a scope for instance of 200MS/s, especially when zooming in.But maybe you've done this test already and you're knowing about this details. Didn't notice that before, your video REVIEW of the DS2000and measuring the wfm/s with the counter brought me to that. Seems to be interesting, that this test can't done with the Hameg HMO, its triggerouput is exactly the trigger of the signal, not the wfm/s.Kind rgds,Gunb

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: March 24, 2013, 10:18:44 am
content: Quote from: Gunb on March 24, 2013, 09:31:08 amWhich is understandable, since (like I said) the scope's processing limits the wfm rate.I don't know what features your DS4000 has but you could try to to enable some more processing functions (i.e. FFT) and you will probably see that the wfm rate drops even more.QuoteIt's probably a different design choice where the acquisition does not stop after a cycle to wait for the scope processing to deal with the sample data. I haven't seen many scopes with such a design, though.

author: Gunb
author_rank: Regular Contributor
timestamp: March 24, 2013, 11:32:43 am
content: Quote from: Wuerstchenhund on March 24, 2013, 10:18:44 amExactly what I've mentioned before. I did not read your comment, without beeing inpolite, ony a lack of time - sorry.Quote from: Wuerstchenhund on March 24, 2013, 10:18:44 amOf couse, what else?! You're right.Kind rgdsGunb

author: marmad
author_rank: Super Contributor
timestamp: March 24, 2013, 11:45:02 am
content: Quote from: Wuerstchenhund on March 24, 2013, 09:09:09 amWell, this is certainly a problem of semantics - perhaps related to circuit design. Obviously, when you do things with the DSO that require processing time, youcanaffect the acquisition rate. But when I talk about display controllers, I'm talking about the actual silicon which drives the panel - which is unrelated to processing or acquisition. You were clearly referring to a block of circuitry encompassing many components, including an ASIC or FPGA which is often shifting the display data to the LCD display controller. BTW, at least on some modern DSOs (such as the Agilent X series - and I'm guessing a few more as well), the main processor is not directly connected to acquisition memory.Quote from: Wuerstchenhund on March 23, 2013, 03:07:27 pmYes, the Rigol does all of these things - although it's analysis of segmented memory captures is limited to mask testing or fairly simple template comparisons. And these are certainly valuable tools for checking signal conformity. OTOH, they all take a certain amount of time - to set up and to run - which starts to add up when many signals are involved. Sometimes for me - and I imagine others that work with circuit design and testing - first looking at real or potential problem signals before more in-depth analysis is a quicker way towards the same point. That is where the higher wfrm/s rate and intensity grading is handy. And I have yet to hear any DSO users say that they didn't like the detail which the intensity grading provided and would return to using slower wfrm/s DSOs - but who knows, maybe they're out there?Anyway, it seems we have different needs with our equipment - although I certainly agree with you that I'd like to see better analysis tools - especially since they could be provided as external software.

author: marmad
author_rank: Super Contributor
timestamp: March 24, 2013, 11:58:50 am
content: Quote from: Gunb on March 24, 2013, 09:31:08 amI never tested this with my DS2000 during the review - I was able to (just) get to the rated 50,000 wfrm/s with sin(x)/x interpolation turned on. But I just ran a very quick test right now using a 1MHz sine wave at 20ns with interpolation off and the rate was 52,780 wfrm/s.

author: jpb
author_rank: Super Contributor
timestamp: March 24, 2013, 01:07:28 pm
content: Quote from: marmad on March 23, 2013, 11:56:14 pmThanks for the link.I've modified my original post as I wrote it before reading the app note properly.With a digital trigger only the samples (plus an extra one in-between) are looked at. The actual time of the trigger event is then got by interpolation. They claim this leads to less trigger jitter which seems odd to me as if the trigger points are either side of a narrow pulse I would have thought that there would be quite a lot of jitter introduce.I can see the big advantage in the removal of blind time but I wonder if there are not some disadvantages which are not immediately obvious.I find this fascinating as an engineer even though it probably has no practical relevance to my use of scopes.

author: AndyC_772
author_rank: Super Contributor
timestamp: March 25, 2013, 08:03:43 pm
content: Here's an amusing observation...My MSOX3054A arrived today, and I couldn't resist checking out the waveform update rate.Fed with a 60 MHz sine wave to trigger on, it manages about 815,000 triggers/sec at 20ns/div.Given that there are 10 divisions on the screen, that's a total displayed time of 200ns. Multiply by the waveform rate and we get 163msec, for a blind time of 83.7%....or do we?It turns out that the 3000X is acquiring a lot more data than it's showing on the screen. If I stop the scope, I can zoom right out until the screen shows 500usec of data, and I can zoom in on that data and see any part of it in full resolution.In other words, it's not triggering, acquiring, displaying and then overwriting - it's capturing all the time, and just picking out bits of the acquired waveform to display. It might not manage to show every possible trigger event on screen, but to say it's "blind" is being a bit harsh. *All* the data is there if you stop acquisition and search for it - and even that can be done automatically.

author: marmad
author_rank: Super Contributor
timestamp: March 25, 2013, 09:45:18 pm
content: Sorry - I deleted my previous response because I thought some more about it and concluded you were right about the sample size.It's a very interesting point that I hadn't considered before. I normally think of blind time as meaning the DSO is blind to data - but now that you mention this, it seems obvious that the strict definition is that it's blind totrigger events- the ADC and ASIC could continue to sample data even as display data is being processed or moved.But I still think that 'blind' time is apt, because as I mentioned before, the main point is that you had to stop the DSO - so you weren't monitoring the wave real-time anymore (i.e. the DSO is 100% blind to any new triggers) - and if you didn't stop it, you would still only be able to monitor that small portion of non-blind time.But I think the bigger question here is: how the hell can one plunk $12k down for an MSO?

author: AndyC_772
author_rank: Super Contributor
timestamp: March 25, 2013, 09:58:16 pm
content: I think you're right. If I put the scope in normal trigger mode and then stop the signal generator before stopping the scope, the extra data isn't available. What's on the screen is all you get. I still think it's a cool feature, though, and a nice touch that I wasn't expecting and wouldn't have missed if they hadn't bothered.ps. just seen you've deleted your previous post, which is a shame because I think you got it spot on!

author: AndyC_772
author_rank: Super Contributor
timestamp: March 25, 2013, 10:00:29 pm
content: Quote from: marmad on March 25, 2013, 09:45:18 pmPatience,keen observation, hard work, and since I do this stuff for a living, tax relief on capital equipment for my business

author: grego
author_rank: Frequent Contributor
timestamp: March 25, 2013, 10:06:25 pm
content: Quote from: AndyC_772 on March 25, 2013, 10:00:29 pmWow because that used scope refurb from Agilent right now is listed at $8000. They accepted an offer like that? Zoikes!

author: marmad
author_rank: Super Contributor
timestamp: March 25, 2013, 10:08:37 pm
content: Quote from: AndyC_772 on March 25, 2013, 09:58:16 pmYeah, sorry, I've been editing and re-editing as my thoughts change about it. For any others who might read this later, my original response was:The operative word here is 'stop'. I don't know what the Agilent does precisely, but it sounds as if when you tell it to stop acquiring, it fills the entire memory (500us / (1 / 4GSa/s) = 2M) on the final acquire. Why do I think it's the final acquire? Because the rated speed of the Agilent X3000 at 50us/div (500us) is 780 wfrm/s - with a blind time of 61% (at 50us/div).But I'm not so sure about that anymore - I thought I remember reading or hearing that the X series used the full sample memory even when looking at a smaller subset. Any other owners want to chime in? But in either case, it's very interesting because it clarifies what blind time really means.Quote from: AndyC_772 on March 25, 2013, 10:00:29 pmOooh..... unfortunately there's no emoticon for drooling - so I'll have to make do with

author: marmad
author_rank: Super Contributor
timestamp: March 25, 2013, 10:43:07 pm
content: @Andy - does the sample rate of the Agilent first drop to 2GSa/s when you set the timebase to 100us?

author: AndyC_772
author_rank: Super Contributor
timestamp: March 25, 2013, 10:51:14 pm
content: Yes

author: marmad
author_rank: Super Contributor
timestamp: March 25, 2013, 11:02:02 pm
content: Quote from: AndyC_772 on March 25, 2013, 10:51:14 pmI really think the MegaZoom ASIC has been designed to keep filling the entire memory post-trigger at the fastest sampling rate unless re-triggered (or unless you are using memory in segmented mode). During the processing and display of the current contents of the sample database (the 'intensity map'), it's blind to triggers - but perhaps it keeps sampling into a buffer.

author: Bitstream
author_rank: Contributor
timestamp: May 02, 2014, 08:09:20 pm
content: FWIW.I was curious how the trigger update rates and trigger blind time (aka dead time) compared for analog vs. digital scopes. I ran tests on the following scopes:*Rigol DS2202 200MHz digital scope*Tek 647A 100MHz analog scope*Tek 7104 1GHz analog scopeThe Tek 647A and Tek 7104 both include a GATE_OUT signal so the trigger rate can be conveniently monitored with a counter.In general, even analog scopes have dead time when the CRT beam is blanked and moved back to the left side of the CRT in preparation for the next trigger. What's interesting is that the analog scopes (at least these 2) do not always have lower trigger blind time compared to the digital scope. In general, the analog scope are better at the faster timebases but start to lose to the digital scope at around 20uS. Newer analog scope may be quicker but I don't have others to test.To calculate the blind time at each timebase setting, I measured the trigger update rate and used the formulas in this Agilent app note:http://www.home.agilent.com/agilent/redirector.jspx?action=ref&cname=AGILENT_EDITORIAL&ckey=1374518&lc=eng&cc=US&nfr=-11143.0.00

author: marmad
author_rank: Super Contributor
timestamp: May 02, 2014, 08:31:22 pm
content: Quote from: Bitstream on May 02, 2014, 08:09:20 pmVery interesting! Thanks for your time and efforts - I always wondered about the comparison to analog scopes.

author: Bitstream
author_rank: Contributor
timestamp: May 02, 2014, 08:49:23 pm
content: You're welcome. Another thing I found interested while collecting the data is that the Tek 7104 scope from the '70s turns in a respectable 560,000 triggers/sec at <=10nS timebase. It must be the magic in those Tek hybrid chips

author: electronics man
author_rank: Frequent Contributor
timestamp: May 02, 2014, 09:36:27 pm
content: I measured 25,000 wfm/s on my rigol ds1074z, will give it another go to see if I can get it to its max of 30000

author: David Hess
author_rank: Super Contributor
timestamp: May 09, 2014, 03:59:51 am
content: Quote from: jpb on March 23, 2013, 10:47:05 pmThis depends on the TDC implementation. Even an integrating TDC can achieve better than 10 picosecond resolution at 50k+ waveforms per second but not by pulse stretching. DSOs that use slow TDCs do so because they have other limitations.

author: David Hess
author_rank: Super Contributor
timestamp: May 09, 2014, 04:09:07 am
content: Quote from: marmad on March 23, 2013, 11:56:14 pmThe analog trigger rearm rate depends on the sweep reset time and not the trigger itself except insofar as it has to detect the other slope before arming. It is quite practical to have triggers which operate into the 250 MHz+ range and some oscilloscopes did this because the trigger was used for other things as well like to drive a frequency counter.Digital triggers are just a variation of a transition midpoint timing TDC.

author: jpb
author_rank: Super Contributor
timestamp: May 09, 2014, 08:53:06 am
content: Quote from: David Hess on May 09, 2014, 04:09:07 amThe LeCroy literature that I originally quoted from was for analogue triggers but in digital scopes. The trigger could be made faster by having a shorter discharge time but this would then make the time measurement less accurate.Such an interpolation approach makes sense if the sample points are comparatively widely spaced and you're trying to catch a fast rising edge. With a 350MHz scope (1nsec rise time) and with the sampling rate at 1GS/s I can see that digital interpolation could be quite inaccurate compared to using an analogue trigger (which my scope does) but it does limit the screen update rate (my WaveJet's update rate is only a few thousand wfms/s).

author: David Hess
author_rank: Super Contributor
timestamp: May 09, 2014, 02:04:36 pm
content: Quote from: jpb on May 09, 2014, 08:53:06 amI remember when LeCroy started advertising their digital triggering. They had some pretty impressive videos of them in action.There are lots of ways to implement a TDC. Dual slope implementations have the limitation you identify and are common on low acquisition rate DSOs simply because a faster TDC would not make them any faster because their trigger rearm time is limited by how quickly they can transfer the current waveform record to the processor. It took oscilloscopes with segmented memory or DPO functionality to require faster TDCs and even then, directly digitizing the output of the TDC (time to amplitude conversion) instead of deintegrating it will get you to at least 200k waveforms per second.http://www.ko4bb.com/~bruce/TDC.htmlSome form of TDC is needed to support equivalent time sampling. Many oscilloscopes lack this now simply because they have high enough real time sample rates but in the past equivalent time sampling was the rule.I have wondered about aliasing with digital triggers. Jitter and nonlinearity in the digitizer will be exasperated by interleaving and the resulting aliasing from the interpolation will corrupt the trigger position but I assume the effect is small enough compared to the supported equivalent time sample rate to be ignored.http://cp.literature.agilent.com/litweb/pdf/5989-5732EN.pdf

author: jpb
author_rank: Super Contributor
timestamp: May 09, 2014, 02:50:40 pm
content: Quote from: David Hess on May 09, 2014, 02:04:36 pmMy WaveJet does have equivalent time sampling (to 100GS/s) and I find it useful. As I don't spend a lot of time glitch hunting I have not noticed the 4k waveforms/s rate as a problem.The waveform per sec rate was pushed to the top of the spec sheet, mainly by Agilent marketing I suspect, but it is a rather ephemeral figure as what ever rate you have there are always a lot of potential glitches that you'll miss. Even at 1Million wfms/s there is still a lot of blind time at the faster time bases. The marketing literature always picks an example that fits in with the waveforms/sec rate of the scope being sold (e.g. Agilent will use very different examples when selling their 3000 series as to there 2000 series).Thanks for the links.

author: marmad
author_rank: Super Contributor
timestamp: May 09, 2014, 02:55:25 pm
content: Quote from: jpb on May 09, 2014, 02:50:40 pmAbsolutely - and the fact that the rate varies widely across the different time bases is not widely publicized. I'm of the opinion that ALL DSOs should display a blind time percentage meter on the screen at all times - just as many show sample rate and size.

author: David Hess
author_rank: Super Contributor
timestamp: May 09, 2014, 02:58:16 pm
content: Quote from: Bitstream on May 02, 2014, 08:09:20 pmHaving a higher blind time at slow sweep speeds on an analog oscilloscope mystified me so I measured my 7904 with 7B92A timebase and at slow sweep speeds, it was always better than 2% at sweep speeds of 200 us/div (2 millisecond sweep) and slower and above that it always measured better than your Rigol.

author: Carrington
author_rank: Super Contributor
timestamp: May 09, 2014, 03:12:31 pm
content: Quote from: marmad on May 09, 2014, 02:55:25 pmThat would be great, should be mandatory.

author: David Hess
author_rank: Super Contributor
timestamp: May 09, 2014, 03:34:25 pm
content: Quote from: jpb on May 09, 2014, 02:50:40 pmAll of my DSOs support equivalent time sampling as well and I have no complaints about it. They have slower waveform acquisition rates than your WaveJet though so I have a fast analog storage oscilloscope for when I need to find rare glitches.Quote from: marmad on May 09, 2014, 02:55:25 pmI would settle for just specifying the blind time at different sweep speeds or publishing the rearm time which would let it be calculated.Displaying this information would be nice but I doubt it will happen. Tektronix at one point considered including a feature on their DSOs which compared the sample rate to the trigger rate (not counting arming) to detect potential aliasing and warn the user but ended up leaving it out because it made their oscilloscopes look bad even though every other manufacturers' DSOs suffered from the same problem. That is what happens when marketing triumphs over a good idea.