Simple Technique to measure Waveform Update Rates: DSOs w/either Edge Triggering - Page 1
Forum section: electronics / testgear

author: marmad
author_rank: Super Contributor
timestamp: May 20, 2013, 08:40:33 pm
content: Edit:As mentioned in later posts, I had assumed that most DSOs could be set to Edge trigger oneither (i.e. every)Rising and Falling edge (as Rigol, Agilent, R&S, Instek DSOs do). This appears to be incorrect - and that many (all?) of the lower-cost ones will only trigger onalternateRising and Falling edges.If you're not sure if your DSO supportseveryEdge, you can test very quickly by setting it to 5ms/div, then sending it asine wave (DS1000 series won't work with square waves)between 1 - 12Hz (step 1Hz). If none of those frequencies produces a stable, non-moving waveform on a single edge, then your DSO is skipping potential triggers - and this technique won't work.

author: marmad
author_rank: Super Contributor
timestamp: May 20, 2013, 08:40:55 pm
content: If anyone uses this technique to finally, once and for all, measure the waveform update rates of the Rigol DS1000 series, the HanTekway DSO5000 series, or any other low cost DSO missing a Trigger Out, I'd really appreciate it if you could post the results in this thread. Thanks!

author: jpb
author_rank: Super Contributor
timestamp: May 20, 2013, 09:02:59 pm
content: Coincidentally I just measured my WaveJet without trigger out this weekend and have just posted the results.But it is not really relevant because the WaveJet keeps a history of the last (up to) 1024 waveforms that can be separately accessed and allows a very simple approach.Without such a history facility, the waveforms need to be all on the screen at once (persistence mode) but I would have thought that with a proper waveform generatora series of increasing pulses could be used - set a burst of n pulses and count how many are captured.

author: marmad
author_rank: Super Contributor
timestamp: May 20, 2013, 09:04:09 pm
content: Quote from: jpb on May 20, 2013, 09:02:59 pmNo, this technique isMUCHsimpler than that: you can measure waveform update rates ofanyDSO in minutes without any special waveform generator (you can even use a PC sound card).EDIT:It appears that Edge Triggering on both Rising OR Falling edges is not the standard feature in low cost DSOs that I believed it was - so I'm trying to figure out an alternative triggering method.

author: jpb
author_rank: Super Contributor
timestamp: May 20, 2013, 09:41:24 pm
content: Quote from: marmad on May 20, 2013, 09:04:09 pmI've now actually watched the video and it does seem a good technique.One drawback is it requires edge triggering on both edges and the WaveJet doesn't do this (it doe either edge or pulse width etc but not both edges). The technique could be varied by using a wave form with say big and small pulses I suppose. If I ever get a waveform generator I'll try this. It also requires a variable frequency source - my only signal sources are a 10MHz oscillator and a 1pps GPS output (I'm somewhat limited equipment wise!).But with the WaveJet, you can just use the time stamps on the captured waveforms, though this only works with short screen memory (which allows a history of a lot of waveforms).

author: egonotto
author_rank: Super Contributor
timestamp: May 20, 2013, 09:45:28 pm
content: Hi marmad,if I understand your method, than I think it does not work on the Hantek-series.The trigger on rise and fall is there an alternating trigger. When it trigger on rise then the next trigger is on fall. When it trigger on fall then the next trigger is on rise.Best Regardsegonotto

author: marmad
author_rank: Super Contributor
timestamp: May 20, 2013, 09:52:29 pm
content: Quote from: jpb on May 20, 2013, 09:41:24 pmReally? Wow, I just thought that was one of those things that was standard on every DSO - it existed on the cheap DS1052E I had.

author: marmad
author_rank: Super Contributor
timestamp: May 20, 2013, 09:56:49 pm
content: Quote from: egonotto on May 20, 2013, 09:45:28 pmHi egonotto,I will look through the Hantek manual to see if there is an equivalent triggering method you can use.Mark

author: Deckert
author_rank: Regular Contributor
timestamp: May 20, 2013, 09:58:06 pm
content: Quote from: marmad on May 20, 2013, 08:40:55 pmThis technique does not seem to work with the Siglent/Atten scopes. No matter what the frequency is that I set, the scope seems to have logic that waits after the first rising edge trigger until it finds a falling edge trigger. It always double-triggers. On 1ms/div I scanned (in 1Hz intervals) from 1Hz to 1000Hz and at no time did it NOT double-trigger.Maybe it's a bug in the Rigol firmware? ... /me runs and hides ...--deckert

author: marmad
author_rank: Super Contributor
timestamp: May 20, 2013, 10:09:05 pm
content: Quote from: Deckert on May 20, 2013, 09:58:06 pmA bug in the Rigol firmware? I'd say a bug in the Siglent/Atten firmware - unless your trigger setting specifically states RisingTHENFalling edge. My DSO manual states RisingORFalling edge, so it's doing exactly what it's supposed to be doing -but it seems your DSO is not functioning correctly. I guess your DSO is supposed to be doing that, but isn't that the same as a Pulse Trigger of indeterminate length?.Edited above after looking at Siglent manual.

author: Deckert
author_rank: Regular Contributor
timestamp: May 20, 2013, 10:31:37 pm
content: Quote from: marmad on May 20, 2013, 10:09:05 pmMark, you're always so serious! Okay, not a bug, but just a behaviour chosen by the manufacturer, as evidenced by the Hantek response. My HP DSO does the same thing as the Atten. I wanted to test it with the PicoScope, but the software does not have a dual-trigger (rising+falling) option.Would love to hear what other Rigol scopes do though!--deckert

author: Deckert
author_rank: Regular Contributor
timestamp: May 20, 2013, 10:41:43 pm
content: Quote from: marmad on May 20, 2013, 10:23:22 pmNot sure why you say the above - the scope clearly triggers on both rising and falling edges - it just waits for a falling edge (and displays it) before triggering on the rising edge again so you can be sure to see both rising and falling edges of a wave, no matter what the frequency. Like I said, my HP DSO (which is decidedly not a cheap scope) has the same behaviour.--deckert

author: marmad
author_rank: Super Contributor
timestamp: May 20, 2013, 10:46:06 pm
content: Quote from: Deckert on May 20, 2013, 10:31:37 pmYeah, I know - sorry, it's a problem some time- I didn't mean to come across that way; I was just surprised by the response. But if you notice in the video the icon that Rigol uses for the menu choice - it clearly representseitherslope - notboth.QuoteQuote from: Deckert on May 20, 2013, 10:41:43 pmAgain - the operative word isOR- notAND. IMO, it seems to me that the Rigol's 'definition' of what it means makes more sense. Triggering on 'Rising THEN Falling' is the same as triggering on a pulse width of indeterminate length - in other words, I can replicate almost the exact same behavior with a Pulse Width Trigger. But to be able to trigger on 'Rising OR Falling' - how do you replicate that with a different trigger type?EDIT:In fact, I'm getting the exact same result you posted above with a Pulse Trigger right now (image). But can you replicate my results with an Edge Trigger that triggers on either edge?

author: marmad
author_rank: Super Contributor
timestamp: May 20, 2013, 11:09:28 pm
content: @deckert - Is your Siglent able to use the operator <> (NOT equal) when using either Pulse or Slope Triggers?

author: Deckert
author_rank: Regular Contributor
timestamp: May 20, 2013, 11:11:10 pm
content: Quote from: marmad on May 20, 2013, 10:46:06 pmNo worries! (like the Ausies say)QuoteI hear you - the icon on the Atten is similar ... i.e. it uses \ or / or X - see screenshot.QuoteMaybe I'm not understanding you here - itdoestrigger on both the falling and the rising edge of the wave. The only difference is that the Atten and HP seem to include logic that will force it to trigger on the edge that it did not trigger on previously?In any event, I'm actually a little disappointed that it does not work on the Atten since I'd really like to know what the official waveform update rate is. Your technique is certainly an interesting one!--deckert

author: Deckert
author_rank: Regular Contributor
timestamp: May 20, 2013, 11:24:40 pm
content: Quote from: marmad on May 20, 2013, 11:09:28 pmHmm, does not look like it. For positive and negative pulses I can see <, > and =, but not <>.--deckert

author: marmad
author_rank: Super Contributor
timestamp: May 20, 2013, 11:25:32 pm
content: Quote from: Deckert on May 20, 2013, 11:11:10 pmNo, the icon on the Rigol is different: look at the attached image.QuoteYes - it's the logic I'm taking about: your Atten (and HP) are only doing Rising AND Falling (they are skipping intervening edges) - whereas the Rigol re-triggersanytimewith Rising OR Falling - it doesn't skip any edges (unless, of course, they fall in the blind time). It's such a pity, because it's SO easy to find the blind time with a Rising OR Falling Edge Trigger!QuoteWell, I'm testing some other possible alternatives.

author: onlooker
author_rank: Frequent Contributor
timestamp: May 20, 2013, 11:37:03 pm
content: Good. This method can be used for DSO that can only trigger on rising or falling edge. You just need to use two channels, or one channel plus trig-in. The triggering channel or the trig-in should have twice the freq as the other channel. The flickering should be looked on the non-triggering channel. Though it may not (?) provide the precise one channel behavior, it well still provide info that can't be easily obtained otherwise.

author: marmad
author_rank: Super Contributor
timestamp: May 20, 2013, 11:50:02 pm
content: @deckert - Can you please run a test to see what happens when you do the following?1) Make sure your DSO frequency counter is on - and the DSO is triggering on Rising AND Falling.2) It looks like the Atten has 18 divs - so set the DSO to the 1ms/div setting (with shortest possible sample length). The DSO can't do more than 55 wfrm/s max. at that setting.3) Try inputting a sine/square wave at 10/15/20/25/30/35/40/45/50/55Hz - and check if the frequency counter accurately displays the frequency each time (and if anything noticeable happens on the display). BTW, I understand that the frequency counter might not measure all the way down to 10Hz - just note from when it does.Thanks, Mark

author: marmad
author_rank: Super Contributor
timestamp: May 20, 2013, 11:52:26 pm
content: Quote from: onlooker on May 20, 2013, 11:37:03 pmUnfortunately, this will drastically alter the single-channel wfrm/s rate - which is the specification normally used by DSO manufacturers. I'm trying to devise a different method using a different triggering technique with a single-channel.

author: onlooker
author_rank: Frequent Contributor
timestamp: May 20, 2013, 11:58:01 pm
content: My guess is trig-in plus one channel should be very similar to one channel behavior if not the same. The verification test should be simple, but, I do not have the setup to do it.

author: Harvs
author_rank: Super Contributor
timestamp: May 21, 2013, 12:08:39 am
content: I had to give this a go on the DS1052 (hacked).Instead of counting divisions on the screen, hit the menu button on the horizontal time base and get the sample rate. Then divide 16k sample points by the sample rate and you've got the theoretical max wfms/s.Given the assumption that:waveform update rate = 1/(sample time + blind time)It didn't take many measurements to get a strong trend that the blind time is quite firm at about 25ms. You can work out the wfms/s from that formula for each of the settings and it's pretty much spot on as far as I can tell with Marmad's method.Hence,500us/div (500ksps) ~= 17wfms/s200us/div (1Msps) ~= 23wfms/s100us/div (2.5Msps) ~= 31wfms/sWith a max wfms/s of around 40. But as you get higher in the sample rate, it becomes more difficult to tell what's going on due to lack of graded display (if that's the right word for it...)Edit: If you want me to try anything else just yell out. But I must leave now to drive across town to pick up my new DS2072.

author: onlooker
author_rank: Frequent Contributor
timestamp: May 21, 2013, 12:19:48 am
content: Actually it made me think an alternatives using double pulse train to do the same thing. Say, the 1st pulse has a width of 10ns and the 2nd, 20ns. The freq of the double pulse train needs to be well below the expected update rate. Now, one can adjust the time interval btw the two pulses from small to large. The moment the 20ns pulse starts to show up at the trigger point, it defines the update rate.

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 12:22:50 am
content: In the video, when I use Edge Trigger on RisingORFalling edge, and my waveform frequency reaches half of the inverse of the minimum acquisition cycle time - my DSO keeps retriggering, but the opposite edge vanishes from the screen.But if you have a DSO that has an Edge Trigger that requires both a RisingANDFalling edge to trigger, it seems to me that when the incoming waveform frequency reaches that same point - your DSO will STOP triggering (WAITin upper corner).Is this not correct?Nevermind... up too late last night

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 12:24:14 am
content: Quote from: onlooker on May 21, 2013, 12:19:48 amYes, this is a known (and published) techniqueI was trying to come up with something easier.

author: Deckert
author_rank: Regular Contributor
timestamp: May 21, 2013, 12:31:29 am
content: Quote from: marmad on May 20, 2013, 11:50:02 pmRight, did all the above.The spec says the hardware counter can't measure less than 10Hz, and indeed it only starts measuring at around 11.7Hz as I slowly crank up the frequency on my func.gen (an analogue model). The frequency is measured correctly though (matches what the frequency counter on the func.gen measures. Through the range from 11.7Hz to 60Hz the hardware frequency counter matches what the func.gen shows, while all the time it's triggering on both falling and rising edges.I didn't see any strange behaviour at any time, except possibly a slight tendency to pre-trigger while in dual-trigger mode. I switched persistence on (that's the fat lines you see in the 50Hz capture, going from 45Hz to 50Hz).The second capture is a sweep (hand cranked) from 10Hz to 112Hz.It's difficult to judge, but I don't think it's reaching 50 wfrm/s at 1ms/div - just seems a bit slower to me.--deckert

author: Harvs
author_rank: Super Contributor
timestamp: May 21, 2013, 02:37:25 am
content: Quote from: Deckert on May 21, 2013, 12:31:29 amYour scope isn't just recording 18 div at 1ms. If you look at the top bar in your screen grab you can see it's not zoomed across the whole sample period.That's why I added earlier to get your sample rate (where ever you can find that in your scope) and divide the sample memory depth by it. You can't just count the number of divisions on the screen. For example, it looks like you're zoomed to about half the samples, which would mean you've got a theoretical max sample rate of about 27 wfms/sec.But what's confusing is it'll look fine because of it effectively aliasing at every integer multiple of the true waveform frequency.Also I found the DS1052 counter to be doing all sorts of weird things while doing this test (like showing 3 hz above the actual frequency.) So I'd suggest using an external counter of some sort.

author: onlooker
author_rank: Frequent Contributor
timestamp: May 21, 2013, 03:11:09 am
content: QuoteOk and thanks for pointing it out.Now more practical thing just to make it a little complete: If one wants to be simple and has a DDS-3X25 USB Arb FG (or the similar), one can get double pulse train with variable timing ratio from one of the digital out pins (e.g. O8) under varies shape of waveform (e.g. exponential) by adjusting the parameters (e.g. the exponent).I tried it on Owon7012. I did not get the trig-in work properly, but, with two channels it worked well.

author: ivan747
author_rank: Super Contributor
timestamp: May 21, 2013, 03:13:14 am
content: Very nice method! I will try to download some sort of sweep generator for my sound card since I am using a DS1102E. The waveform update should be slower than the DS2102E and since you were always below 20kHz I assume I can do this. Let's see how it goes. I will start tomorrow morning, it's 11 at night here.

author: jpb
author_rank: Super Contributor
timestamp: May 21, 2013, 09:04:00 am
content: This does seem a good approach only frustrated by the fact that most scopes are designed to trigger on only one type of edge.The obvious solution, as several have pointed out, is to have pulses in pairs with one being say twice the height of the second but this requires an AWG.But I'm wondering if a simple rectifier circuit would do it. You'd want a full wave rectifier with a gap induced by the diode voltage drop which would be frequencydependent and the amplitude of one branch of the rectifier could be reduced using a series resistor (or else a dc offset used on the input sin wave).

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 11:12:28 am
content: Quote from: jpb on May 21, 2013, 09:04:00 amSorry, but I'm think you're wrong with this deduction; I'm not sure what you're basing it on. I had assumed that Edge triggering on either edge was a standard on most DSOs - it seems such an obvious (and simple) feature to offer - and a quick check of manuals shows that Agilent DSOs, GW-Instek DSOs, Rohde & Schwarz DSOs, and at least one type of LeCroy DSO (WaveSurfer), in fact,doit.So that means - with info gathered so far - we have Agilent, GW-Instek, R&S, and Rigol making scopes that trigger on either edge - LeCroy (except for one series?), Hantek, and Siglent (and Owon, I think) making scopes that don't. So which group designs more DSOs?To me, the strange thing is that DSO manufacturers would instead implementalternateEdge triggering - which isvery similarto Pulse triggering; another standard trigger type offered in most DSOs - but noteither- which is not similar to other standard triggers.Edit:I've been updating this with more manufacturers that make DSOs witheitherEdge triggering as I look through manuals.

author: jpb
author_rank: Super Contributor
timestamp: May 21, 2013, 12:03:55 pm
content: Quote from: marmad on May 21, 2013, 11:12:28 amFor the purposes of this experiment it is not the ones who design the most DSOs (or even those that sell the most) that matter, but rather whether scopes which don't have trigger output have either edge triggering.The present experiment aside, in general the ability to trigger of either edge is not something that is often used I would have thought. If, for example, you had both positive and negative pulses in a signal, they would require different trigger levels as well as different polarity of edge triggering so if you're having to decide on the level you can also determine which sort of edge you're looking for.The only circumstance that I imagine I might want to use such an option is if I wanted to capture the front and backends of a long pulse repeatedly with normal triggering - say to look at the rise and fall times at the same time.

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 12:18:55 pm
content: Quote from: jpb on May 21, 2013, 12:03:55 pmTrue - but this experiment aside - you wrote: "...most scopes are designed to trigger on only one type of edge" - which is what I responded to - and which, it seems to me, is wrong.QuoteWell, again, the evidence to the contrary may be the number of manufacturers/DSOs which offer it. The obvious reason for having it is when you want to make sure to trigger on an edge - but you don't know which edge to expect - as in this experiment - and other circumstances I can think of.QuoteAs mentioned before, this can be easily accomplished with a standard Pulse Width trigger - so havingalternatingEdge triggers (as Hantek, Siglent, etc. offer) is rather unnecessary (and a waste, IMO). OTOH, triggering oneitheredge can't easily be accomplished with another trigger type.

author: ivan747
author_rank: Super Contributor
timestamp: May 21, 2013, 01:01:30 pm
content: Quote from: jpb on May 21, 2013, 09:04:00 amActually, we only need square waves, and we only need sub-MHz bandwidth, so you could try to program a micro controller to do this.

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 01:31:55 pm
content: Quote from: Harvs on May 21, 2013, 12:08:39 amWell, I can't speak about the DS1052E - but with the DS2000, the blind time is highly variable. Here they are (roughly) for 14kPts (in the measurable range where active acquisition time >= 7us, i.e. the minimum acquisition time @ 2GSa/s) - varying between 54 and 2857us:

author: Harvs
author_rank: Super Contributor
timestamp: May 21, 2013, 02:15:49 pm
content: Quote from: marmad on May 21, 2013, 01:31:55 pmYep, it just goes to show how much faster the DS2000 is. It may well have varied by 1 or 2ms, but the overall time is so long it's hard to notice properly.

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 02:30:59 pm
content: Quote from: Harvs on May 21, 2013, 02:15:49 pmBut I am curious to know what the DS1000E series wfrm/s rate is in the 50ns - 500ns range (where most DSOs hit their peak speeds); I've heard many figures bandied about.

author: Harvs
author_rank: Super Contributor
timestamp: May 21, 2013, 02:33:45 pm
content: Ok I'll give it a go tomorrow, I'm pretty sure it's not capable of getting over 40 though from what I did today.

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 02:35:34 pm
content: Quote from: Harvs on May 21, 2013, 02:33:45 pmGreat... thanks!

author: jpb
author_rank: Super Contributor
timestamp: May 21, 2013, 02:52:11 pm
content: Quote from: marmad on May 21, 2013, 01:31:55 pmInteresting results. The blind time shows a definite pattern - it drops with the time base down to 50 microseconds and then goes up to a roughly constant value.I surmise that the number of points grabbed in the acquisition is more than 14,000 by a few hundred. If by 14k they mean the normal 14*1024 then the active acquisition time for say 5ms/div is not 14*5ms but (14*1024/14,000)*5ms. It is a small difference at the shorter timebases but is significant at the longer ones and would account for much of the blind time I think.Doing a quick calculation on the longest timebases of the ratio of Acquisition Time/Active Acquisition Time comes to 1.02 (i.e. your 2% from the table) which is very close to 1024/1000 = 1.024. So it looks as if the blind time is purely down to filling in a bit of excess buffer space due to using whole ks.

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 03:05:15 pm
content: Quote from: jpb on May 21, 2013, 02:52:11 pmNo, they meanprecisely14000 bytes. The Rigols sample lengths are based on the 14 divisions of the screen - and so are exact multiples/divisions of that - always 7, 14, 28, or 56.And, BTW, as I wrote, the table is rough - so I'm not sure you can really draw many sampling conclusions from it. For example, I think I measured those figures while in Dot mode, and the rate at 20us is specificed at 2394 wfrm/s. Wel, when you make the same measurement with Vectors (interpolation) turned on, the rate jumps to close to 3000 wfrm/s (as in the video).

author: jpb
author_rank: Super Contributor
timestamp: May 21, 2013, 03:15:30 pm
content: Quote from: marmad on May 21, 2013, 03:05:15 pmThe screen is exactly 14,000 samples but in the buffer I would expect them to stop the acquisition when the top 4 bits reach 14, ie at 0xE in hex with the rest of the 14 bits being zero, only the first 14,000 samples would be used but it would have acquired 14*1024 before stopping. It makes much more sense to just check 4 bits than 14 and a 2% difference is not worth the extra complexity of trying to stop at a number which though round in decimal terms is not in binary terms.I accept that the table is rough, but that fits in with my hypothesis otherwise you'd get slightly negative blind time because of the difference between 2.4% and 2%.

author: ivan747
author_rank: Super Contributor
timestamp: May 21, 2013, 03:18:48 pm
content: I haven't been able to find the blind time on my DS1102E. I've been trying for hours. Time to check the manual. Maybe the trigger is not the same as the DS2000 series or I'm doing something wrong.

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 03:38:33 pm
content: Quote from: jpb on May 21, 2013, 03:15:30 pmI think you're overestimating the complexity of code required - and underestimating the wasted time it would take to 'fill excess buffer', as you put it. Given a sample length of 14,000,000 points vs. 14,680,064 points (as you suggest), the extra time needed to acquire those added points would be 340us per acquisition cycle (@ 2GSa/s). And why check bits? Can't the FPGA just decrement to zero?

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 03:48:53 pm
content: Quote from: ivan747 on May 21, 2013, 03:18:48 pm@ivan747:Well, I'm not 100% sure that the DS1000E series allowseitherrising or falling Edge triggering. Despite what I believed earlier, it's appearing more and more like cheap DSOs (and LeCroy) don't offer this feature - and that it's only available on higher-end DSOs.But you can tell very quickly by just going to the 10ms/div time base setting, then sending your DSO a square wave of 1, 2, 3, 4, and 5Hz. If one of those frequenciesdoesn'tstop your DSO from triggering on both edges (and produce a stable, non-moving waveform), then the DS1000E series is doingalternatingEdge trigger - instead ofeitherEdge - and this technique won't work.

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 04:19:06 pm
content: Quote from: jpb on May 21, 2013, 03:15:30 pmWhen using 14MPts sample length, the wfrm/s rate (at any time base < 1us) is 142 - proving that the DSO is capturing 14,000,000 points -not14,680,064 points (14 * 1,048,576) - since in the latter case, the blind time would be negative.

author: jpb
author_rank: Super Contributor
timestamp: May 21, 2013, 04:32:18 pm
content: Quote from: marmad on May 21, 2013, 03:38:33 pmI shouldn't think that they take it to that extreme. But if they are filling sample buffer at a rate of 2GS/s then it would be much easier for them to only count the samples in whole 1024 units which would reduce the counting rate to a more reasonable 2M/s. Then if they need to do this at the high sample rates they probably wouldn't change the architecture for the slower rates.I don't know what the buffer arrangements are but on their earlier scopes they used multiple DACS and perhaps they have two banks of 8x128bytes of high speed memory on the front end which is filled alternately and only transferred to slower memory when it is filled. So that they effectively have 2 very high speed 1k buffers which are switched between with one being filled whilst the other is being emptied into slower RAM.With 14MPts it will sample 13,672*1024 points = 14,000,128 points which will not affect the wfm rate significantly.So my proposal is that there is a minimum sample unit size of 1024 due to high speed buffer memory and the other numbers are in whole numbers of these units.At 14,000 it is 14 units (13 would be too few) while for the bigger numbers the granularity is less important and actually smaller for the 14MPts case.

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 04:50:35 pm
content: Quote from: jpb on May 21, 2013, 04:32:18 pmThe architecture (post-ADC) of the DS2000 is VASTLY different; it is in no way similar to the earlier DS1000E series - which used the same 512kB*8B SRAM as sampleANDdisplay memory. The DS2000 has 3x 32MB*16B DDR2 for sample memory, as well as 2x 512kB*36B display SRAM. The image (from Dave's teardown) shows the ADC (bottom), FPGA (heat-sinked), and the DDR2.

author: tinhead
author_rank: Super Contributor
timestamp: May 21, 2013, 05:43:59 pm
content: Quote from: marmad on May 21, 2013, 01:02:12 pmnah, alternating trigger is very usefull thing (even if costs DSOs postprocessing time to switch between channels), maybeeven more usefull than dual edge trigger. On the other side is good to have all of them.Quote from: marmad on May 20, 2013, 08:40:55 pmthe latest HanTekway firmware (actually last 5 or so) supports dual edge trigger. However the implementation is not in DSOcore (so not in FPGA) but in UI (ARM firmware), which means it does nothing else than simply re-arm trigger with differentedge value. In principle dual edge triggering is nothing else, but in "DSO" part of the firmware, not after all in the let's callit software. What i miss in HanTekway version is that it does trigger once and not twice when in single shot.I've tested it anyway, nothing catched (no blanks, stops, what so ever - except by 30/40/50 sometimes flickering due thematch to selected display refresh rates).I've tested with dual edge and single edge, in 1 Hz steps (each every second 1Hz change to ensure i see the "glitch") between10Hz and 3kHz (and that was real pain in the ass), trigger of course set to normal, filtered signal (to ensure that as much as possible noise is triggering).A side note:i know the FPGA register where the "amount of captured trigger evens per FIFO" is located. The ARM firmwareseems to be using this for e.g. waveframe counting, so i assume that's what we looking for.When i read it back, i get max. of 0x7FF when the DSO is working with "empty buffer" (oh well, when i ground inputs, so datais there but the postprocessing in FPGA takes almost no time). This seems to be the highest value, so 2047 waveframes/s.When a real waveform is applied, the number is going down to near 2000 while on 800ns/DIV (which seems to be the fastesttimebase), when i change timebase i can clearly see difference, e.g. at 2us/DIV avg. 1236 waveframes or at 20ns/DIV only513 waveframes, etc.That's the numbers from latest two FPGA designs, with the very first FPGA design for hw0 i got max. 0x8ff.Knowing that these DSOs are working DPO-like, i would say this are the real wfms/s numbers, but yeah, as always, thisis only what i assume from what i see on FPGA or saw when comparing to TEKhttps://www.eevblog.com/forum/chat/hantek-tekway-dso-hack-get-200mhz-bw-for-free/msg174242/#msg174242But still, it would be nice if someone with Hantek/Tekway/Voltcraft and dual channel AWG/Signal-gen could use the differentmethod and calculate wfms/s based on what on UI.

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 05:46:46 pm
content: Quote from: tinhead on May 21, 2013, 05:43:59 pmYou're making a mistake - we're not talking about Alternate trigger - we're talking about Edge trigger on EITHER (i.e. EVERY) edge or ALTERNATE edges.QuoteAgain,as mentioned here, easy to test at 10ms/div. If your DSO does not produce an un-moving waveform with 1, 2, 3, 4, or 5Hz - then it IS NOT triggering oneveryedge - butalternateedges (it's skipping potential triggers). From what I can tell of the Hantek, it does NOT doeveryedge.

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 06:08:52 pm
content: Just to clarify - since there seems to be some misunderstandings here - for this technique to work with a DSO, it must support EITHER (Green) Edge triggers (which I thought was common, but now seems to be limited to higher-cost DSOs), not ALTERNATE (Red) Edge triggers (which seems to be what is implemented in cheap DSOs)Quote from: tinhead on May 21, 2013, 05:43:59 pmYes, this sounds likealternateEdge - which introduces logic into the situation - instead of just triggering on every edge, whatever it may be.

author: jpb
author_rank: Super Contributor
timestamp: May 21, 2013, 06:29:04 pm
content: Quote from: marmad on May 21, 2013, 04:50:35 pmOK I accept that the architecture is different, but I am convinced that there is some sort of high speed 1k buffer probably within the FPGA - (for comparison Dave has mentioned that Agilent has all their memory in the FPGA to allow high speed) - which restricts the granularity of sampling to 1024 samples as a minimum unit.DDR2 likes data to be transferred 64bits at a time, the DAC is producing 8bit samples but at very high speed (i.e. 2GS/s) so there must be some sort of buffer with 8bits x 2G in and 64bits x 250M out, in fact DDR2 can go up to 3.2GB/s with a 100MHz clock but it needs to be 64bits wide to reach this.Some sort of buffer is needed, I'm just postulating that this buffer is 1024bytes.

author: tinhead
author_rank: Super Contributor
timestamp: May 21, 2013, 06:40:13 pm
content: Quote from: marmad on May 21, 2013, 06:08:52 pmi was just about to write "fuck, can you not just read what i wrote? bit less emotions and few more seconds to readwhat others wrote is more useful" .. and before i did it, you posted this

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 06:45:55 pm
content: Quote from: jpb on May 21, 2013, 06:29:04 pmPossibly. Although, since the Rigol's sample memory really is divided into units of 7 (7kPts per channel), and the Spartan-6 has 8kB (no parity) of dual-ported RAM, 8192 bytes might be a better guess.

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 07:06:40 pm
content: Quote from: tinhead on May 21, 2013, 06:40:13 pmSorry- sometimes people don't hang around after posting, and since, at the beginning of your post, you mixed-up the trigger types that I meant, I just wanted to point that out quickly in case you were 'leaving' to run other tests. But I did go back and finish reading your postSo I guess it was just a misunderstanding because of semantics? An "alternating Edge Trigger" as opposed to an "Alternate Edge Trigger" (or "Alternate Trigger in Edge mode")?

author: tinhead
author_rank: Super Contributor
timestamp: May 21, 2013, 07:08:58 pm
content: Quote from: marmad on May 21, 2013, 05:46:46 pmout of curiosity, is it working as well with single shot mode on Rigol DS2000 ?Quote from: marmad on May 21, 2013, 07:06:40 pmexact, that was the case.

author: KedasProbe
author_rank: Frequent Contributor
timestamp: May 21, 2013, 07:22:57 pm
content: I tried it on my Hameg HMO1022 it also has no trigger out, and it seems it also uses alternate trigger for 'Slope=Both'.

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 07:27:47 pm
content: Quote from: tinhead on May 21, 2013, 07:08:58 pmIf I do a single shot with a 1Hz square wave coming in, sometimes I will see the rising edge - sometimes the falling edge - it just depends on which edge happens to trigger the acquisition when I press 'Single'.

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 07:33:50 pm
content: Quote from: KedasProbe on May 21, 2013, 07:22:57 pmThat's too badBut the Hameg has some nice triggers - maybe there's an alternative; I'll glance through the manual.

author: tinhead
author_rank: Super Contributor
timestamp: May 21, 2013, 07:47:54 pm
content: Quote from: marmad on May 21, 2013, 07:27:47 pmhmm, even when you set signal source to short pulse (short enought to be shown complettly on display) each every 1Hz?Just thinking how can Rigol DS2000 trigger oneitheredges when it does only on "which ever first" (as you said right now),which looks like then likealternate

author: jpb
author_rank: Super Contributor
timestamp: May 21, 2013, 07:58:55 pm
content: Quote from: marmad on May 21, 2013, 06:45:55 pmOK here's my latest thought - the 2000 series shares an architecture with the 4 channel 4000 series so the 8k is split into 2 buffers per channel (allowing one to empty while the other is filling) for 4 channels giving the 1k buffer size! I'll now stop.

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 08:04:48 pm
content: Quote from: tinhead on May 21, 2013, 07:47:54 pmAn 'alternating' Edge trigger means that EVERY trigger begins with a Rising edge and ends with a Falling edge- Or that's what I had been thinking earlier (but, of course, no simple DSO to check it on). The other possibility is that it just triggers on the next available alternate Edge.An 'either' Edge trigger means that it triggers on ANY incoming edge - alternate or not.The DS2000 also has the Delay trigger - with two possible sources - both of which can be set to either Rising or Falling edge - and any channel - so you can have alternate Rising edges - or alternate Falling edges - trigger the DSO.

author: Deckert
author_rank: Regular Contributor
timestamp: May 21, 2013, 08:54:06 pm
content: Hi,Just for completeness sake, here are the trigger modes, as explained in the manual for the Siglent/Atten.--deckert

author: ivan747
author_rank: Super Contributor
timestamp: May 21, 2013, 09:10:08 pm
content: Quote from: marmad on May 21, 2013, 03:48:53 pmDoesn't work at all. Tested from 1Hz to 7Hz in 0.5Hz steps.

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 09:12:08 pm
content: Quote from: Deckert on May 21, 2013, 08:54:06 pmIt would probably be more clear if they used the word 'then' instead of 'and'.Ugh I need food

author: ivan747
author_rank: Super Contributor
timestamp: May 21, 2013, 09:26:19 pm
content: I believe it's possible, as someone mentioned earlier, to achieve the same effect. On an oscilloscope that works using alternate edge triggering.Just place a wave (square preferably) on channel one of a frequency F. On the trigger channel, apply a signal in phase, of a frequency 2F. Trigger on the rising edge of the Trigger channel. You should achieve the same effect as Marmad's original idea. I am trying this right now.Note: a good way to do this in hardware is a simple square wave generator( could be 555, function gen. or sound card) and a frequency divider using a flip-flop.

author: Deckert
author_rank: Regular Contributor
timestamp: May 21, 2013, 09:32:22 pm
content: Then I think the Siglent/Atten scope works differently to how you think it does. If the signal rises, the scope triggers. If the signal falls, the scope triggers. That looks like "either" (or OR) to me. It definitely doesn't wait an entire cycle before it triggers again.However, the scope makes sure that I don't miss the falling edge, no matter what the timebase (or frequency) is. That sounds more preferable to me.--deckert

author: ivan747
author_rank: Super Contributor
timestamp: May 21, 2013, 09:43:10 pm
content: Cheers! Just tried my method and it works on the Rigol DS1102E. Tested on the 10ms timebase, both sine waves, trigger is at 4Hz and CH1 is at 2Hz, the waveform only displays the falling edge. It does this on 5Hz/10Hz (Ch1/Trig.).My setup is very rudimentary, consisting of my computer, Audacity and some crocodile clips hooked to an RCA connector and probe hooks.EDIT: that was with CH2 turned on. Now that I turned it off it behaves even more like the original post.On 3 and 4Hz at CH1 only one edge of the trace appears. On 5Hz, it starts to alternate again.Does anyone knows how to make a sweep stay in phase with another sweep of twice the frequency? I have a sweep generator in Audacity. I can specify amplitude, start and end frequency and if I want linear or exponential sweep.

author: tinhead
author_rank: Super Contributor
timestamp: May 21, 2013, 09:48:53 pm
content: Quote from: Deckert on May 21, 2013, 09:32:22 pmand this is exactly what HanTekway is doing as well, the single shot on DS2000 looks to me like it does exact the sameas well too. So probably in run mode DS2000 is simply triggering twice (on both edges, which was exactly what irequested from Hantek as a fix for their current " both edges" implementation), which (i guess) could explain why on Rigolone edge disapears when reached the blind time window.

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 09:53:22 pm
content: Quote from: Deckert on May 21, 2013, 09:32:22 pmBut your scopewon'ttrigger on two rising - or two falling - edges in a row; they have to alternate. And that's exactly how I think it works. And sorry, but no, that's not the definition of 'either' (i.e. every).QuoteOf course you're missing edges - more than with a true 'either' Edge triggerThat's why 'either' Edge exists - so you see as many edges as possible.

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 10:41:53 pm
content: Ok - I got some food so I could think clearly again - and finish my diagram [correctly - I think!]@deckert:This diagram shows a DSO needing both alternating Edges to trigger the acquisition; the frequency of the input signal is just over half the inverse of the minimum acquisition time.Note: red = accepted trigger / black = missed or ignored trigger / green-orange = blind time / gray = waiting for triggerOn the DSO with 'alternate', the waveforms per second becomes a quarter of the maximum rate.On the DSO with 'either', the waveforms per second becomes half of the maximum rate (as shown in the video).EDIT: (I had been thinking that the diagram above illustrated an 'alternating' Edge trigger - but it must be the one below since, according to reports, both edges remain visible.)This diagram shows a DSO needing a single alternating Edge to trigger the acquisition; the frequency of the input signal is just over half the inverse of the minimum acquisition time.Note: red = accepted trigger / black = missed or ignored trigger / green-orange = blind time / gray = waiting for triggerOn the DSO with 'alternate', the waveforms per second becomes a third of the maximum rate - missing or ignoring 2 triggers between each acquisition.On the DSO with 'either', the waveforms per second becomes half of the maximum rate (as shown in the video) - missing or ignoring 1 trigger between each acquisition.

author: darrylp
author_rank: Regular Contributor
timestamp: May 21, 2013, 11:09:59 pm
content: Well 2.4.1sp2 firmware on an upgraded 1052e without sin(x)/x on gets a max of 20 wfms. Hmm. That's even down to 2ns timebase.Turning on sin(x) reduces to 13 on some timebase and 14 on others.The ds1052e on listed firmware does both triggering.20 wfms from 50us downwards. msand higher timebases where down in single digit updates.--Darryl

author: onlooker
author_rank: Frequent Contributor
timestamp: May 21, 2013, 11:22:54 pm
content: So it is worse than Owon7102? Why didn't I see more talkings about this? Just kidding.

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 11:27:39 pm
content: Quote from: darrylp on May 21, 2013, 11:09:59 pmAccording to other DS1052E users in this thread, the DSO doesnotdo 'every' Edge triggering - but instead does 'alternate' Edge triggering. If this is true, the video method does not work.

author: darrylp
author_rank: Regular Contributor
timestamp: May 21, 2013, 11:37:18 pm
content: well its working on mine ( hence mentioning the firmware on it )the screen shows the same sort of imageas in your video Marmad, when you first show the square wave. i can then get it to loose the left down trigger, and the counter (also with a T in the front of it, as I had the trigger on, and using the normal setting as per your DS2072 ) then goes squiffy. ie. its showing double of my function gen input. then tops out around the 40Hz on the counter, but 20Hz on the FG. going higher on the FG and the counter on the scope goes down ... not down to half, like you were seeing on the external trigger out, but down it goes. so 21Hz on FG shows 33.76Hz on counter ( that was one time i wrote down ) but not sure what timebase that was now.ie wasnt using persistance vision, used vectors instead of dots, as only at low timebase where the dots mode usable on the 1052e for this test.

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 11:39:08 pm
content: Quote from: tinhead on May 21, 2013, 09:48:53 pmI don't know what you mean by this - what are expecting the single shot to look like? IMO, it looks exactly as it should.QuoteI explain in some depth in the video why one edge disappears. There is no mystery about it - it's clear as a bell.And you can also see why inthe previous diagram.

author: marmad
author_rank: Super Contributor
timestamp: May 21, 2013, 11:43:19 pm
content: Quote from: darrylp on May 21, 2013, 11:37:18 pmOk, great! I wasn't sure from other reports if it worked on the DS1052E - I'm glad to know that it did. Thanks for posting your results - very interesting.

author: Harvs
author_rank: Super Contributor
timestamp: May 21, 2013, 11:54:28 pm
content: Quote from: marmad on May 21, 2013, 02:30:59 pmResults I got, DS1052E hacked to 1102,500ns/div 36 or 37 wfms/s50ns/div 39 wfms/s

author: ivan747
author_rank: Super Contributor
timestamp: May 21, 2013, 11:55:33 pm
content: @marmadIt's possibly the firmware. I have firmware 00.04.00I just can't get it to work with your original method. What i have noticed is that on some frequencies with alternate edge triggering, the waveform update rate is very fast and on others it slows down to a point where it can show one particular edge say 10 times more often than the other, but I have never managed to get it to display only one edge due to blind time effects.With the method I described earlier I can, and it works just the way it should, at least on the timebase I tested it on. I am going to build a frequency divider circuit so I can do sweeps with the Audacity plugin I have installed. It's the only way I can do sweeps for the moment.

author: ivan747
author_rank: Super Contributor
timestamp: May 21, 2013, 11:56:21 pm
content: Quote from: Harvs on May 21, 2013, 11:54:28 pmCan you please post your firmware version? The fact you hacked it tells me it is 00.02.somethingFurther testing on my 00.04.00 FW unit reveals something interesting. I generated 5 cycles of a sine wave function at 1Hz. This means it *should* trigger 10 times, 2 times per cycle if it has the "real" alternate edge triggering. In practice, using a 10ms timebase, I can count only 4 triggers. That is:1st cycle rising: triggered1st cycle falling: no trigger2nd rising: no trigger2nd falling: trigger3rd rising: no trigger3rd falling: no trigger4th rising: trigger4th falling: no trigger5th rising: no trigger5th falling: triggerIs you want me to go even slower I can hook up a pot to this oscilloscope.

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 12:03:18 am
content: Quote from: Harvs on May 21, 2013, 11:54:28 pmThanks for that, Harv! It does surprise me though - I was sure the DS1052E was in the neighborhood of 50 - 100 wfrm/s at the smallest time base settings.

author: darrylp
author_rank: Regular Contributor
timestamp: May 22, 2013, 12:07:06 am
content: Quote from: Harvs on May 21, 2013, 11:54:28 pm@Harv, are you sure you didnt miss the flickering at approx half these values ? are these number from the on screen counter ? which is twice the input freq. ?my posted 20Hz input was showing 40Hz on the DSO counter.thus, thinking your 39wfms is ( close to my 20 ... if you were using the scopes numbers that is ;-) )

author: Harvs
author_rank: Super Contributor
timestamp: May 22, 2013, 12:13:45 am
content: Firmware is 02.04.I initially had a lot of problems trying to get it to work, in fact I gave up at one point yesterday. Then just by chance I fired up my AWG and scope and there was a single edge displayed on the screen. Turns out I had been looking in the wrong frequency range, which you can then end up with aliasing that makes it look like it's sort of working but its not.If you set your function gen to a 13Hz sinewave, scope on either trigger, with sample depth to normal and a timebase of 1ms/div you should firmly be in the blind time and only see one edge.

author: Harvs
author_rank: Super Contributor
timestamp: May 22, 2013, 12:18:03 am
content: Quote from: darrylp on May 22, 2013, 12:07:06 amI'm definatly not using the DSO counter, that's way off.Part of the problem with this method is it's easy to stuff up because you can get the same results at integer multiples of the "true" frequency.Now I'm not saying that I'm the "right" one here, I may be completely wrong, but what I did was to calculate the theoretical maximum wave frequency from the sample memoy depth and sample rate and use that as the starting point. Then wind back from there.I wonder if there's an internal signal in the scope that I could solder some lead onto and probe? Might have to pull the back and have a look.

author: ivan747
author_rank: Super Contributor
timestamp: May 22, 2013, 12:28:13 am
content: Quote from: Harvs on May 22, 2013, 12:13:45 amExact same settings, this is what I see (infinite persistence on so you can figure it out).(btw, the file is supposed to be called bad_trig.bmp It's a pain in the ass to write filenames on the Rigol)

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 12:32:36 am
content: Quote from: Harvs on May 22, 2013, 12:18:03 amWell, that's exactly the problem I had when trying to use a decreasing frequency - I was hitting the multiples. I didn't have that problem when increasing the frequency - the very first 'blank' or flickering area I found was always the 'correct' double of the minimum acquisition cycle.

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 12:35:48 am
content: Quote from: ivan747 on May 22, 2013, 12:28:13 amBut you shouldn't be using persistence at all - it greatly alters the wfrm/s rate. In fact, you should be trying to avoid using any other features at all - including frequency counters, other channels, etc. For DSOs with slow wfrm/s, anything you add beyond a single channel on - is likely to noticeably affect the rate.I used the frequency counter on my Rigol in the video because it barely changed the rate. But the first time I ran the tests I just used the frequency from the FG.

author: ivan747
author_rank: Super Contributor
timestamp: May 22, 2013, 12:40:43 am
content: Quote from: marmad on May 22, 2013, 12:35:48 amFair enough, turned everything off, persistence, counters, measurements, channels, Sinx /x interpolation and ejected the drive. Same effect. There's something different about our units.

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 12:53:15 am
content: Quote from: ivan747 on May 22, 2013, 12:40:43 amYes, it really sounds as if Rigol, for some reason, might have changed the behavior of the Edge trigger in your version of the firmware.

author: ivan747
author_rank: Super Contributor
timestamp: May 22, 2013, 12:53:30 am
content: I have just tried a 13Hz wave on CH1 with a 26Hz wave on Ext trigger. Trigger on the rising edge, trigger channel. 1ms timebase. Works. It only displays on edge.Even messing around with the menus causes the edge to change, presumably, it stops capturing the trigger because it is servicing the menu. As Marmad says, turning on persistence changes the acquisition rate. Still, my previous screenshot illustrates what I meant in the post.

author: ivan747
author_rank: Super Contributor
timestamp: May 22, 2013, 12:54:51 am
content: Quote from: marmad on May 22, 2013, 12:53:15 amShould be interesting to see if the waveform acquisition rate changed with the update as well. Let's find out!

author: Harvs
author_rank: Super Contributor
timestamp: May 22, 2013, 02:01:40 am
content: Ok so I hit some luck.Probing around in the internal headers of the DS1000E series has some very interesting signals on them. For the purpose of this discussion though, I found the trigger output.

author: Harvs
author_rank: Super Contributor
timestamp: May 22, 2013, 02:08:13 am
content: Now onto the measurements. For the first couple I wanted to verify that this signal was in fact correct, so I started by feeding in a lowish frequency square wave and observing the trigger signal. The DS1052 was set on rising edge trigger. I got the same numbers on either edge trigger, but for saving the waves it was cleaner to just use rising edge.Channel 2 is the wave feed into the DS1052, and channel 1 is what I believe to be the trigger output. I have turned persistence on to demonstrate what's happening on the falling edge. This becomes more significant later on, but it pretty much corresponds to exactly half the time it's taking to perform a waveform cycle.Now at 12.4Hz input on 1ms/div, it starts to jump triggers, so I believe this is the max wfm/s.

author: Harvs
author_rank: Super Contributor
timestamp: May 22, 2013, 02:15:54 am
content: Now it's a PITA to observe the rate in this method, so I tried the traditional method of feeding in a fast pulse train, worked a treat.So using that technique I measured the waveform rate for each time base setting.Above 5us/div there wasn't a noticeable change so I stopped recording values.I've attached the scope grab at 5ns/div to explain what is happening though. There is a significant change in speed from one to the next. The peak speeds are around 65wfm/s and then the next cycle it'll drop to 40wfm/s. So I guess it depends on what you're going to use this info for, but if you need to garrentee you're going to capture an event, you'll need to use the 40wfm/s number.

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 02:26:17 am
content: Quote from: Harvs on May 22, 2013, 02:01:40 amNice find!! I'm rather amazed no one has located this before.Quote from: Harvs on May 22, 2013, 02:15:54 amWell, these numbers are closer to what I was expecting for the DS1052E - but I'll still surprised they didn't climb a bit higher up to at least the 200ns/div. setting.QuoteYes, this can happen at certain frequencies - triggers might hit the edge of the blind time (or a multiple of the blind time) and cause the rate to fluctuate.

author: Harvs
author_rank: Super Contributor
timestamp: May 22, 2013, 02:45:15 am
content: Quote from: marmad on May 22, 2013, 02:26:17 amBut whats really needed to do is characterize the shortest and longest acquisition times. I've only just got the DS2000, so I haven't looked in-depth yet but can it do this automatically?The problem is the amount it jumps around.So I've just hooked up my ancient HP 5381A freq counter because it does a simple dumb rising edge count which you can run for 10sec. So the attached figure is for a 10sec integration period, but I guess I tend to find this fairly useless info.

author: Harvs
author_rank: Super Contributor
timestamp: May 22, 2013, 02:48:37 am
content: Quote from: marmad on May 22, 2013, 02:26:17 amSorry I just saw this comment. I don't think it's just this. There is a significant and constant change in the amount of time it takes between cycles on every timebase and with every input signal.I get the feeling that perhaps the processor is time shared between doing something with the waveform data and other duties.

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 03:06:07 am
content: Quote from: Harvs on May 22, 2013, 02:45:15 amPress Measure -> Statistic to turn the statistic function on or off. When the statistic function is enabled, press StatisSel to select “Extremum” or “Difference” measurement. When “Extremum” is selected, minimum and maximum values are displayed. When “Difference” is selected, standard deviation and count values are displayed.To view the history measurement data, press Measure -> MeasHistory -> “ON”. The history data can be displayed in two modes:1) Graph: display the results of multiple measurements of at most 5 measurement items that are turned on last in graph mode. The measurement points are connected using linear interpolation.2) Table: display the results of the last 10 measurements of at most 5 measurement items that are turned on last in table mode.

author: eKretz
author_rank: Frequent Contributor
timestamp: May 22, 2013, 03:06:17 am
content: I was curious about the waveform update rate on my scope after seeing you guys post, I just got my first - a Tek TDS 754a. Here are the numbers I got, I was using 15k pts mem in the fast wfm/s mode (Insta Vu).50ns - 330,000 wfm/s100ns - 230,000 wfm/s200ns - 200,000 wfm/s500ns - 120,000 wfm/s1µs - 60,000 wfm/s2µs - 30,000 wfm/s5µs - 11,200 wfm/s10µs - 6,000 wfm/s20µs - 3,050 wfm/s50µs - 1,200 wfm/s100µs - 625 wfm/s200µs - 325 wfm/s500µs - 125 wfm/s1ms - 62 wfm/s2ms - 25 wfm/sI had a frequency counter on the external trigger out while triggering on a 27MHz waveform, is that an OK way to measure? I'm still pretty new to scopes, is this update rate pretty good?

author: alank2
author_rank: Super Contributor
timestamp: May 22, 2013, 03:07:22 am
content: Quote from: marmad on May 21, 2013, 12:24:14 amWhere can I find information about this technique? I've been messing with a microcontroller to produce a pulse train described above, but the counter on the scope (rigol) would count both pulses even if it doesn't flicker back and forth between the the two different sized pulses.

author: ivan747
author_rank: Super Contributor
timestamp: May 22, 2013, 03:15:14 am
content: Quote from: alank2 on May 22, 2013, 03:07:22 amMy interpretation of what he meant is on page 5, you can take a look at that. Maybe it's not the correct interpretation but it works for our purposes.@Harvs: I will confirm if my DS1102E shows the same update rate with the method I described earlier. I'm not opening my oscilloscope. Too expensive for me to void its warranty. By the way, what firmware are you using? And please try Marmad's method to see if it works, because on my FW 00.04.00 it doesn't work, so I made a work-around. It's described in page 5 of this thread.And wouldn't an isolated trigger output be a sweet mod to try?

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 03:22:52 am
content: Quote from: alank2 on May 22, 2013, 03:07:22 amI described it in-depth beforein another thread here- and I think you can also find similar techniques written about elsewhere online - although I don't have any links offhand.BTW, the method referred to in the link describes using a dual-output function generator - but that is simply to make it easy to adjust the distance between the pulses. If you are generating the pulses with software (e.g. a microcontroller), a single output is fine.

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 03:33:15 am
content: Quote from: eKretz on May 22, 2013, 03:06:17 amSure, that's the easiest (and best) way to measure. And yes, those are definitely good update rates - perhaps the Tek TDS-700 series were the top of the wfrm/s heap before the Agilent 3000/4000 X-Series came along?

author: Harvs
author_rank: Super Contributor
timestamp: May 22, 2013, 04:33:59 am
content: Thanks Marmad. I gave it a go, but the results weren't particularly conclusive. I'm probably doing something wrong, I assumed that by feeding in a 40MHz siginal to trigger it, then I would be able to trigger it every time. But I get different minimums depending on whether it's 40MHz or 35MHz.Anyway, I think for the DS1000 series I've probably put about as much effort into this one as I'm going to. I've got some reasonable results, I know that above about 40 wfms/s it'll start dropping the odd trigger (which is what I saw in the original method.)The trigger out on the other hand could be worth putting some time into. I don't think isolation is needed, as for anything I can think of it'll be triggering another mains earth reference device. But a high speed 50ohm driver would be a definite requirement. But yeah, that would need to go to the end of the list of other projects I've got on the go at the moment.

author: KedasProbe
author_rank: Frequent Contributor
timestamp: May 22, 2013, 06:07:16 am
content: Quote from: marmad on May 21, 2013, 10:41:53 pmIf you would have to choose between 2 then alternate is better, you do sometimes (not always) miss a 'trigger' but it guarantees than you will always see both edges on your screen for all frequencies. But obviously your method needs a missing edge on the display for some frequencies.

author: darrylp
author_rank: Regular Contributor
timestamp: May 22, 2013, 07:42:44 am
content: Quote from: darrylp on May 22, 2013, 12:07:06 amoh dear, now being awake... I realise my posts last evening here in the UK, it was early morning, and being tired you shouldnt be posting tech info !20Hz input double ( edge triggered ) and detected by the scope was like 40Hz on its counter, and that indeed is what the scope saw, and updated on. so it was updating at 40wfms, not my half posted values of the input. so i was seeing ~40wfmssorry for my confusion !Darryl

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 08:41:30 am
content: Quote from: darrylp on May 22, 2013, 07:42:44 amAh..yes... I have suffered the same fate too many times to count. No worries - that's what Modify and Remove are for!

author: tinhead
author_rank: Super Contributor
timestamp: May 22, 2013, 08:57:38 am
content: Quote from: marmad on May 22, 2013, 03:22:52 amherehttp://www.storeinfinity.com/blog/Waveformrefreshrate

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 09:17:09 am
content: Quote from: KedasProbe on May 22, 2013, 06:07:16 amSpoken like someone who's DSO does 'alternate'.Seriously though, this isn't a contest - and both methods have their advantages. The 'either' method guarantees a higher wfrm/s rate: for example, at 5us/div on my DSO - given a 5kHz waveform input frequency - my wfrm/s rate is 5000 - but it would only be 3750 using the 'alternate' method.Ideally you would be able to chose the method you prefer, but only a few DSOs offer both options (Agilent X-Series, LeCroy WaveSurfer, some R&S DSOs, etc). My personal feeling is that if I don't have a choice, I would prefer that the DSO doesn't perform 'logic' on my triggers - so I would favor the faster wfrm/s. If I just happen to be observing an exact waveform frequency that lands in the blind time (like the above example: causing me to lose an edge - but maintain a higher wfrm/s rate), a simple menu button press allows me to alter which Edge I'm looking at. Also, the DS2000 has 16 different trigger types, so if I need to see both edges at the same time I have other options.

author: KedasProbe
author_rank: Frequent Contributor
timestamp: May 22, 2013, 01:00:43 pm
content: I would be a nice feature if the scopes just display the time between the last sample and the next first sample (can't be a hard thing to do in the firmware). Because that's what you want to know, how much time (or %) am I missing on the screen.Different settings are changing this value so I would almost think it's a must have when you measure something, so why aren't they adding it.

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 01:39:41 pm
content: Quote from: KedasProbe on May 22, 2013, 01:00:43 pmAbsolutely! Very easy to do in firmware, I would think - although sometimes it's bouncing around a lot - so with some kind of averaging would probably be best.QuoteWhy do you think? Did you notice the posted speeds of the DS1052E? They don't really want comparisons.

author: alank2
author_rank: Super Contributor
timestamp: May 22, 2013, 01:52:42 pm
content: Quote from: marmad on May 20, 2013, 08:40:33 pmI tried this last night with older firmware (DS1102E) and I couldn't get a stable waveform. I updated to newer firmware and the same result.10ms timebase, edge trigger, slope has both up and down arrows, sweep normal, sensitivity 0.1div, holdoff 500ns1 Hz to 5 Hz square wave all produce a back and forth waveform where it captures the rise on one and then the fall on the next, like a rail road crossing alert...Thanks,Alan

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 01:56:25 pm
content: Quote from: alank2 on May 22, 2013, 01:52:42 pmAnd yet some here have posted that it works on (at least certain versions) of the DS1052E FW. Strange.

author: Harvs
author_rank: Super Contributor
timestamp: May 22, 2013, 02:25:36 pm
content: Quote from: alank2 on May 22, 2013, 01:52:42 pm10ms/div is a bloody long time. There's no point measuring at this level as it'll be mostly all acquisition time.If you have a look at the tables I've produced earlier, use these as a starting point (i.e. known value) and you should be able to wind it back from there and find it works fine. The real problems are encountered when you are triggering off integer multiples and don't know it.EDIT: Sorry I just read the post you were replying to. That came across the wrong way. The method works fine though with the DS1000 series (within reason.)

author: alank2
author_rank: Super Contributor
timestamp: May 22, 2013, 02:27:07 pm
content: So I switched to a sine wave, and here it is stable:1Hz stable2Hz not stable3Hz stable4Hz not stable5Hz stableTriangle works the same as sine. Back to square wave and all are not stable.

author: Harvs
author_rank: Super Contributor
timestamp: May 22, 2013, 02:35:08 pm
content: Quote from: marmad on May 20, 2013, 08:40:33 pmI haven't properly read this before, and I'll caveat what I'm about to say by the fact it's getting late here.But this seems to assume that your scope is going to capture an even multiple of 10ms divisions right? Or am I off here?Unlike on the DS2000, the DS1000 hardly ever displays all of the data captured. In fact some time bases are effectively just zooms of others (i.e. they have the same capture length at the same sample rate, and just reduce the amount that it shows on screen.) So the timebase and screen divisions is not an effective measure of the acquisition time. As I've said earlier in the thread, if you need to know the acquisition time on a DS1000, just hit the menu button to get the sample rate, and divide sample memory depth by it.

author: ivan747
author_rank: Super Contributor
timestamp: May 22, 2013, 02:41:37 pm
content: Quote from: alank2 on May 22, 2013, 02:27:07 pmSeems like I am the only one that cannot get this to work on my DS1102E. I still think it's the firmware.Can anyone confirm Marmad's method doesn't work on a DS1000 series scope with a 00.04.00 firmware?Thanks

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 02:46:35 pm
content: Quote from: Harvs on May 22, 2013, 02:25:36 pmThe 10ms/div setting is just a simple test point to see if your DSO does 'either'or'alternating' Edge triggering. You could test at any time base setting - but the slower ones only have a limited range of frequencies before one of the edges HAS to hit the blind time and then vanish ('either') or stay visible ('alternating').QuoteBut the point is, hehasone of the DS1000 series - and he's saying it doesn't work with his model/firmware combination.

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 03:06:11 pm
content: Quote from: Harvs on May 22, 2013, 02:35:08 pmNo, this has nothing to do with divisions per se - it's only related to the acquisition cycle time - which, as I mentioned in the video, is always the longer of either (time base * divs) OR (sample length / sample rate).QuoteI'm pretty sure most DSOs work in (more or less) the same way. The sample time is controlled by the sample rate; when you set a sample length (e.g. 1kPts), the DSO sets the sample rate to (at a minimum) fill the display time. So if you're at 1ms/div (x 10divs = 10ms display time) each sample has to be 10us - so the effective sample rate is set to 100MSa/s. Some DSOs actually change the frequency of the ADC clock - some just keep the same ADC clock rate and decimate unused samples. But at smaller sample lengths (< ~100kPts) and larger time base settings (>= ~1us) the samples often just fill the screen with no overflow.

author: alank2
author_rank: Super Contributor
timestamp: May 22, 2013, 03:08:35 pm
content: My first report was with long memory. Normal memory depth on sinewave:1 Hz stable2 Hz not stable3 Hz not stable4 Hz stable5 Hz not stable

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 03:26:50 pm
content: Quote from: alank2 on May 22, 2013, 03:08:35 pmAlan - I'm not sure if your DSO is correctly doing 'either' Edge triggering - but it might be that I've miscalculated just how slow the DS1000 series is.Why don't you try 2ms/div? This is more reliable because we have data from this setting. According to Harvs chart below, the wfrm/s rate at that setting is 5.62 - which means the acquisition cycle time is ~178ms - with a blind time of ~154ms. That means if you give the DSO asine waveof 4Hz (250ms period = 125ms edge to edge), it shouldn't trigger on the opposite edge (it will definitely fall in the blind time) - so if you see both edges, it's doing 'alternating' Edge triggering - if it remains locked on the rising (or falling) Edge, it's doing 'either'.

author: alank2
author_rank: Super Contributor
timestamp: May 22, 2013, 03:40:00 pm
content: 2ms timebase, normal mem depth, edge, slope both up and down, normal sweep4 Hz sinewave - rising only (stable)4 Hz triangle - rising only (stable)4 Hz square - alternating rising and falling (unstable)

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 03:43:44 pm
content: Quote from: alank2 on May 22, 2013, 03:40:00 pmAnd is your trigger level at 0V?

author: alank2
author_rank: Super Contributor
timestamp: May 22, 2013, 03:45:15 pm
content: I mean the trigger sweep mode=normal (not auto or single).4 Hz is stable.

author: alank2
author_rank: Super Contributor
timestamp: May 22, 2013, 03:46:36 pm
content: Yes, Trigger level at 0V

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 03:50:06 pm
content: Quote from: alank2 on May 22, 2013, 03:45:15 pmYes, I 'doh'ed that shortly after I wrote itthen erased the commentQuote from: alank2 on May 22, 2013, 03:46:36 pmWell, either the DS1000 has different logic depending on the rise time speed - or the rise time speed is affecting the normal logic - but it seems as if it's working with the sine wave, so just run your tests (only using sine) and see what you get.

author: alank2
author_rank: Super Contributor
timestamp: May 22, 2013, 04:03:28 pm
content: 1ms timebase7-12 Hz - stable13-20 Hz - unstable21-24 Hz - stable25-33 Hz - unstable34-35 Hz - stableSo does this mean 20 waveform updates per second???

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 04:12:33 pm
content: Quote from: alank2 on May 22, 2013, 04:03:28 pmHey - did you watch the video?Seriously, though - the maximum waveform per second rate is always the frequencyright before (or just as)you exit the FIRST stable period. In this case 12-13Hz - which matches exactly with Harv's measurement of the Trigger Out. No need to keep scanning after you've had the first blind time (only a single-edge visible - or as you call it, stable).

author: alank2
author_rank: Super Contributor
timestamp: May 22, 2013, 04:14:42 pm
content: Quote from: marmad on May 22, 2013, 04:12:33 pmI did, but I had distractions while watching it, or at least that is my excuse!So odd that it doesn't work properly with square waves...

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 04:15:36 pm
content: Quote from: alank2 on May 22, 2013, 04:14:42 pmI'm guilty of the same often myself.

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 04:21:48 pm
content: Quote from: alank2 on May 22, 2013, 04:14:42 pmIt might be, as I mentioned before, some kind of decision by Rigol's engineers to assume a user might want to see both edges when there is a fast rise/fall time - and so they use 'alternating' Edge logic then. Actually, it's not such a bad idea if it's true: you would get the fastest wfrm/s rate with slow rise times ('either') - but the benefit of seeing both edges with fast ('alternating').EDIT:In any case, I've re-edited the first post to 'sine wave' instead of 'square wave', in case other Rigol owners try the test.

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 04:31:03 pm
content: Quote from: ivan747 on May 22, 2013, 02:41:37 pm@Ivan- have you run the test using a sine wave? It appears square waves don't work with the Rigol DS1000 series - but sine waves do.At 2ms/div, the wfrm/s rate of the Rigol is 5.62 - which means the acquisition cycle time is ~178ms - with a blind time of ~154ms. That means if you give the DSO a sine wave of 4Hz (250ms period = 125ms edge to edge), it shouldn't trigger on the opposite edge (it will definitely fall in the blind time) - so if you see both edges, it's doing 'alternating' Edge triggering - if it remains locked on the rising (or falling) Edge, it's doing 'either'.Test it with these settings:2ms/divNormal mem depthEdge trigger -> both slopesNormal sweep4Hz sine wave

author: Teneyes
author_rank: Frequent Contributor
timestamp: May 22, 2013, 04:54:41 pm
content: Quote from: alank2 on May 22, 2013, 03:40:00 pmWith Trigger set at 0 Volts, could the Square wave be 0-> x Volts, and Not + - ?

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 05:31:28 pm
content: Quote from: Teneyes on May 22, 2013, 04:54:41 pmGood point - I didn't think to ask. But as long as a sine wave works for him, it doesn't really matter.

author: alank2
author_rank: Super Contributor
timestamp: May 22, 2013, 05:33:17 pm
content: Hi,Quote from: Teneyes on May 22, 2013, 04:54:41 pmI tried it both ways. I have a TTL output on my AWG (it is a cheap one off ebay) and I set the trigger for the middle, and it also has an output that produces a balanced square wave and I trigger it again in the middle (0V).

author: darrylp
author_rank: Regular Contributor
timestamp: May 22, 2013, 05:38:44 pm
content: Quote from: alank2 on May 22, 2013, 05:33:17 pmyou have the setup on the trigger on 0.1 div, and minumum holdoff of 500ns ( these are the lowest values that my 2.4sp1 firmware allow.its working for me... I get slightly lower figures in these 5us to 10ms range than Harv, but its similar. mine is hardware 58 ( from memory when I was last inside when I replaced the cooling fan with larger ( quieter ) one )

author: ivan747
author_rank: Super Contributor
timestamp: May 22, 2013, 06:06:37 pm
content: I got Marmad's original technique to work on my oscilloscope now. Thanks for the hint Marmad! (via PM)I was expecting a much faster update rate on the oscilloscope. I started on a 10ms timebase. Apparently not even 1Hz is slow enough for that. I got it to work on 4Hz at the 2ms timebase. But I can't still find anything else on the scope, so:QuoteI was doing something wrong. Sorry for the confusion.I'll grab the wfrm/s table someone posted earlier and try to confirm it is the same in this firmware. Also I want to try from scratch using frequency sweeps.

author: ivan747
author_rank: Super Contributor
timestamp: May 22, 2013, 06:19:02 pm
content: Still, can someone try this method on the "dodgy" LeCroy and Atten oscilloscopes that skip edges on their triggering?It's the following:*Get 2 frequencies, one called F1, the other F2. Try square and sine waves, whatever works best.*F2 is twice as fast as F1 and these are in phase.*Set your trigger to the Ext. trigger channel, on the rising edge, normal trigger, not auto.*Connect F2 to the Ext. trigger channel.*Connect F1 to Ch1 (leave Ch2 off).*Start looking for the same phenomenon described in Marmad's video, everything should work the same in that regards.I tried this with the same settings as my last post, obviously with the exception of the points I just mentioned. It displays only a single edge, so it works more or less the same. Granted, if your blind time changes because of the external trigger, that can affect your measurements, but I don't see why the blind time could increase with external trigger.

author: marmad
author_rank: Super Contributor
timestamp: May 22, 2013, 06:22:38 pm
content: Quote from: ivan747 on May 22, 2013, 06:06:37 pmWell, it was more my mistake for suggesting 10ms/div to you as a test point. I've now re-edited the first post to suggest people first test on 5ms/div with a sine wave frequency from 1 - 12Hz. I think this will work for most DSOs (that have 'either' Edge triggering). On the Rigol DS1000, it should produce a stable image at 1 or 2Hz.

author: tinhead
author_rank: Super Contributor
timestamp: May 22, 2013, 09:47:35 pm
content: Quote from: ivan747 on May 22, 2013, 06:19:02 pmthis didn't make any sense, twice the frequency as trigger will always produce "expected" result.If you don't believe apply 50MHz/100MHz and you will see it works as well, and i doubt your DSO is capable of actually what? 50M or 100M wfrm/s?

author: ivan747
author_rank: Super Contributor
timestamp: May 22, 2013, 10:18:46 pm
content: You go from the lowest frequency to the highest. The first time you get the expected result is the waveform update rate. The same problem could happen on Mark's (marmad) method using alternate edge trigger. I don't know if we can call it aliasing, but it's sort of like that.

author: Teneyes
author_rank: Frequent Contributor
timestamp: May 22, 2013, 11:51:33 pm
content: Interesting to see that my Rigol DS2072 Update rate change from 46,000 wfrm/s to 5K wfrm/s when changingthe scan rate from 20nsec/div to 20.1nsec/div. But understandable.

author: tinhead
author_rank: Super Contributor
timestamp: May 23, 2013, 12:02:41 am
content: Quote from: Harvs on May 22, 2013, 02:01:40 amHarvs,that pin could be sync to logic analyzer module as well, and not trigger out.Another thing is, with long memory enabled you should got different values, a real trigger out should get affected by sample memory changes.Anyway, you can do another one test (maybe you ran it already?), apply only single pulse, then two, then burst, etc and compare it with the "trigger out" you found,if that's really trigger out then there must be no difference (on each pulse/burst you need to get signal there).Quote from: marmad on May 22, 2013, 02:26:17 amprobably nobody was really looking for, but when you check attached picture you will see that Rigol is having some kind ofphase/trigger delay? circuit (i found it as well in older Rigol series, as well in ATTEN, Tekway A series, Hantek hw1005,Siglent. Attached schematic of Hantek's version of that circuit as well, Rigol is almost the same).That could be another place to look for trigger out.Something else to watch (for those who checked with "edge disapears" way) is not to get fooled with display refresh sync,Rigol DS1000 seems to have display refresh rate menu, when value changed the estimated wfms/s should not change whenthe DSO-core is in FPGA only, when in DSP as well then it should change when DSP running single thread, but when more threads thenit should remains (almost, there can be some overhead) the same (as the display thread should have no influence on capture/postprocess thread).

author: onlooker
author_rank: Frequent Contributor
timestamp: May 23, 2013, 12:11:42 am
content: Again maybe someone already did this. Here is a better version of double pulse method using DDS3x25 with the attached waveform.1). It work for single channel.2). Easier to operate: It detects the flicking point by adjusting the oscilloscope's trigger level.3). Better at filtering out false triggering.For details see the picture.On the scope, move Trig level up and down to find the level where flickering starts showing up. At this point the green time interval defined the waveform update rate. The scope should be on DC coupling.At 10Hz run of this waveform on FG, the change of scope trig level covers the update rate from about 50Hz to 1kHz. The range can be changed by changing FG running freq (e.g 5Hz run covers wfm upd rate from 25Hz to 500Hz).The long flat part of the waveform is about 80% of total. It is the way to overcome/reduce the aliasing effect (false trig at wrong FG running freq) .

author: marmad
author_rank: Super Contributor
timestamp: May 23, 2013, 12:22:15 am
content: Quote from: onlooker on May 23, 2013, 12:11:42 amWhat DSO did you test it on?

author: onlooker
author_rank: Frequent Contributor
timestamp: May 23, 2013, 12:34:12 am
content: I tried a few settings on Owon SDS7102 (bought after watching your videos and before you changed your opinion).I am more interested in the discussion about methods, than detailed numbers. Besides, I remember you had already listed the numbers from trig-out a while back.

author: marmad
author_rank: Super Contributor
timestamp: May 23, 2013, 01:26:20 am
content: Quote from: onlooker on May 23, 2013, 12:34:12 amI was just trying to understand whether you actually tested the claims that you made; e.g. "... the change of scope trig level covers the update rate from about 50Hz to 1kHz." But in any case, it's an interesting idea - unfortunately, many low cost DSO owners don't have AWGs - hell, some of them have had to dig around to come up with a method for sweeping a simple sine wave to test my method.Anyway, I'm off to bed, but I did some quick testing. It seems to be reasonably accurate with my DSO update rate until the 500us/div setting (~140 wfrm/s) - then starts losing accuracy more and more at each smaller time base setting. I only tested to 20us/div, at which point it was off by ~20% - although I'm sure it's probably possible to increase the accuracy with further tweaking of the sample period/frequency.I used the double pulse method for checking wfrm/s with the DDS-3X25 quite some time ago - and the Hantek software just becomes excruciating to work with after awhile.

author: Harvs
author_rank: Super Contributor
timestamp: May 23, 2013, 01:44:16 am
content: Quote from: tinhead on May 23, 2013, 12:02:41 amYeah I imagine that's it's actual purpose. There's a few signals on that header that seem to correspond to certain events in the sampling process.QuoteHow should it get affected? I don't understand, I thought a trigger out just has an edge that corresponds to "time zero" on the scope? How does that change with long memory depth?QuoteSorry I don't understand what a burst of pulses is likely to do? In all the test previous I've feed in a 30MHz square wave and it only outputs when the scope triggers (this is in the screen shots earlier), is this what you mean?

author: marmad
author_rank: Super Contributor
timestamp: May 23, 2013, 02:12:57 am
content: Quote from: Harvs on May 23, 2013, 01:44:16 amThe maximum number of triggers a scope can output at any given point is the inverse of the acquisition cycle time. The acquisition cycle time includes the acquisition time - which, as I wrote in my last post to you, isalwaysthe longer of either (time base * divs) OR (sample length / sample rate). With long memory depths, it's almost always the latter - so the waveforms per second (and the number of trigger out pulses) would then decrease. Now please don't make me write this againEdit:BTW, almost EVERYTHING you can do on a DSO affects the wfrm/s rate (and thus the Trigger out): persistence, measurements, extra channels, having a menu out, etc. because they change the variable blind time (i.e. the DSO is doing more processing).

author: marmad
author_rank: Super Contributor
timestamp: May 23, 2013, 02:46:05 am
content: BTW, blind times for these rates are (approximately):2ms154ms1ms68ms500us38ms200us30ms100us24ms50us21ms20us18ms10us18ms5us17ms

author: Harvs
author_rank: Super Contributor
timestamp: May 23, 2013, 04:12:01 am
content: Quote from: marmad on May 23, 2013, 02:12:57 amOh, he was referring to the "values" of the waveforms per second! hehehe, I thought he was coming up with some other totally left field test where by the memory depth will change the inherent behavior of the trigger output system.Seriously I need more coffee...And no Marmad, you actually didn't ever need to state that, it's perfectly apparent in my mind. What's not apparent to me is exactly how many samples the DS1000 takes at any given setting. I use to think it was always 2^14 (16k) / number of channels when on normal memory depth, regardless of the timebase setting (i.e. the timebase setting just changed the sample rate and "zoom" of the display). But this discussion has made me wonder if my assumptions were wrong. However, when I get the chance I'll do some raw dumps over USB and see what I get out.tinHeadBack to the discussion about the "trigger out", I'm guessing what you're getting at, is does the trigger show edges when the scope is acquiring samples. I.e. is it just a pass through from the trigger circuitry. I can defiantly say it's not. You can throw as many pulses you like at it, and it will only have a rising edge when the scope actually is triggered.

author: tinhead
author_rank: Super Contributor
timestamp: May 23, 2013, 10:44:43 am
content: Quote from: Harvs on May 23, 2013, 04:12:01 ami would not say pass through, the trigger flag/option etc. need to be set and fullfiled to produce output here, but thisstill didn't means the DSO postprocessed the data and stored it in some buffer (like on DPO or all modern DPO-like DSOs)or send it to display (or display buffer) which is the case for typical DSOs.When you check the available memory in DS1000E, you will see there is not enough to have 2 x 8k or 1x16k bufferwithin FPGA. There are 423936 bits, div by 10 ADCs and by 8bit per ADC thats 5299.2bits - more realistic fromimplementation point of view is therefore 4096bit max. Even if not full 4k but e.g. 1k are used per ADC, the DSPstill need to read multiple times or there is different architecture in FPGA (which we don't know, see below).In HanTekway DSOs i can see in FPGA two FIFOs, each 2048bit deep and 16bit wide. That's 65536bitand already twice the reqiered size for "4ksamples per channel", so i assume this are the DPO-like buffers.I assume the FPGA is using dual port ram for sampled data, so 8 ADCs x 8bit x 4096deep, that's are 262144bits.So together there are 327680bits used (from 423936 available), and still lot of (96256bit) for what so ever function.Knowing this (and the fact that i can set trigger by writing specific FPGA register and read back sampled data withoutrunning the ARM app) i could say that IF there is similar trigger-out signal on FPGA (it is actually there as specificFPGA register readback) then this will be a real trigger-out data.Did i forgot something? Yes is did, this is only valid for 4ksamples per channel, when HanTekway is using more(24k, 40k, 512k, 1M or 2M) then that data is going then to external SRAM before moved into display buffer.That means trigger-out should send "triggered pulse" 10x when memory depth is set to 40ksamples (or only oncewhen the FPGA design is smart enough). I assume it is the last case, because as i patched once the ARM firmwareto beep on trigger it was only once beep per 40k.All the other things the DSO is doing with the sampled data need to be count as well as part of acuisition step- especially when we talk about DSO, for DPO-like gears this might be difficult to say. Example Tek TDS700A,when DPO enabled the DSO can be still getting slower when adding measure, cursor, etc (but the trigger out didn'tdrop here as it comes from the sampling core and not UI).I can only guess what Rigol DS1000E is doing in FPGA, two 4k deep FIFOs, each 16bit wide (two FIFOs mae senseas we have two DSO channels). Then 10 dual port buffers (for 10ADCs) x 2k deep x 8bit wide. The remained129024bit are for what so ever DSO functionality in FPGA. However there is still open question how they managedto run 5 clock domains in EP3C5 FPGA, and are they skipping sampled data 4 times to write FIFO? They can as welluse external SRAM to store the 16k, this is what we don't know.An hardware "clone", e.g. ATTEN (what so ever, one of the old models) is having only 4k when the SRAM is not populated,so it can be that Rigol is using the external SRAM for these 16k already. If that's the case, the question "is the trigger outyou found a real trigger out or only sync signal to LA" is still valid. Additionally Rigol DS1000 was never announced to workas DPO-like DSO, so we need for sure take into calculation how the data is being sampled, stored and postprocessed beforewe use the signal you found for what so ever calculations.

author: tinhead
author_rank: Super Contributor
timestamp: May 23, 2013, 11:12:57 am
content: Quote from: ivan747 on May 22, 2013, 10:18:46 pmi know what you mean, but tests with external signals are anyway tricky.Example, I've tested HanTekway with the two signal method, e.g. result for 20us/IDV was 488us delaywhen 50Hz display refresh selected (so 2049 wfms/s) and 358us when 30Hz display refresh (2793wfms/s).When i measured with the dual edge trigger and extern triggering (as proposed by you), and started fromlow to high frequency, i got 244 wfms/s which is near the avg. 2421/10 which i got by using two signal method.And of course i got as well higher values with dual edge and external trigger when i increased test signal frequency.So what is the real value? Pure visual by comparing with TEK TDS700, and as well by testing with (programmed) glitchi would say Tekway told the truth and their DSOs can something 2000-2500wfms/s. They selling these DSOs as DPO-like,the sampled buffer speaks for it (see my post above).On the other side, the probability to have 1/10 and think to have 10x times is not that smallBtw, i have only WaveForms AWG (wtih sound card), this is not the best solution for testing due step size in delay,it takes a lot of time so i will not check deeper. Other FGs i have are only one channel, and unfortunately i hadno luck today, there was niceYokogawa FG120on ebay 330925343592So still, when someone have HanTekway/Voltcraft and 2ch AWG with delay, then please check the wfms/s with the twochannel method (or with one channel Hantek AWG and the ramp/pulse method).

author: marmad
author_rank: Super Contributor
timestamp: May 23, 2013, 12:52:43 pm
content: Quote from: Harvs on May 23, 2013, 04:12:01 amHe, he. One problem we have here in trying to discuss technical data is that there's almost always one portion of the forum in need of either sleep OR coffee.QuoteYou're right - I never realized this about the Rigol DS1000 - but when I calculated from charts of the sampling frequencies available here in the forum, these are the number of actual sample points being displayed at each time base setting (out of a possible 16kPts):Points displayed from 16k sample length (DS1000E series)5ns 6010ns 12020ns 24050ns 600100ns 600200ns 600500ns 6001us 1,2002us 2,4005us 3,00010us 3,00020us 3,00050us 3,000100us 3,000200us 3,000500us 3,0001ms 3,0002ms 3,0005ms 3,00010ms 3,00020ms 3,000Points displayed from 14k sample length (DS2000 series)5ns 14010ns 28020ns 56050ns 1,400100ns 2,800200ns 5,600500ns 14,0001us 14,0002us 14,0005us 14,00010us 14,00020us 14,00050us 14,000100us 14,000200us 14,000500us 14,0001ms 14,0002ms 14,0005ms 14,00010ms 14,00020ms 14,000

author: ivan747
author_rank: Super Contributor
timestamp: May 23, 2013, 02:37:14 pm
content: Quote from: tinhead on May 23, 2013, 11:12:57 amThanks for the test. The Ch1 signal can be derived from the external trigger signal by using a frequency divider. It can be done with a flip-flop and a function generator with TTL output.Now that we have tables for the DS1052Es, and now that I know I can use the original method to compare, I could try this with a lot of patience. My problem right now is that I never bothered buying a function generator. It's not on my list of priorities because I mostly do MCUs.

author: marmad
author_rank: Super Contributor
timestamp: May 23, 2013, 05:02:05 pm
content: @onlooker:Could you please test your method on your Owon SDS7102 with the following settings:1k Sample LengthCH1Horizontal: 500ns/divTrigger type: Rising EdgeTrigger mode: NormalPlease let me know what number you receive. Just report whatever you find (even if you think it's wrong) because this is a blind experiment.

author: marmad
author_rank: Super Contributor
timestamp: May 23, 2013, 11:21:52 pm
content: Since we've been discussing acquisition cycles and blind times, it occurred to me that I wasn't 100% sure about the precise definition of the active acquisition time (screen time or samples?). I had assumed it was whichever was longer (in time) - but I wanted to check the literature.After re-reading the two most oft-quoted documents on the subject,thisandthis, it appears, strangely enough, that Agilent and Rohde & Schwarz define this critical piece of information differently!Agilent's lit. states:"A scope’s dead-time percentage is based on the ratio of the scope’s acquisition cycle time minus theon-screenacquisition time, all divided by the scope’s acquisition cycle time."Rohde & Schwarz's lit. states:"The acquisition cycle consists of an active acquisition time and a blind time period. During the active acquisition time the oscilloscope acquires thedefined number of waveform samplesand writes them to the acquisition memory. e.g. 100 ns (1000 Sa, 10 GSa/s). "So Agilent considers points captured, but not displayed, as part of the blind time - but Rohde & Schwarz doesn't.So for example, given the following settings:1GSa/s sample rate1k sample length (so sample time is 1us)10ns/div. time base10 divisions on screen (so onscreen time is 100ns)100k wfrm/sAgilent's lit. states:"% DT = Scope’s dead-time percentage= 100 x [(1/U) – W]/(1/U)= 100 x (1 – UW)whereU = Scope’s measured update rateandW = Display acquisition window = Timebase setting x 10"So according to Agilent's specifications and formula, the blind time is 99%.R&S's lit. states:"acquisition rate = 1 / acquisition cycle timeblind time ratio = blind time / acquisition cycle time"So according to R&S's specifications and formula, the blind time is 90%.Strange. But perhaps it's just a question of semantics: Agilent feels if you can't see it on the display, it's not relevant - but R&S feels that it's still data that's been captured and can be analyzed if needed?

author: ivan747
author_rank: Super Contributor
timestamp: May 23, 2013, 11:51:59 pm
content: If you take the term blind literally, you will see Agilen's definition is more accurate. You can't see all the information in the oscilloscope's memory in real time.

author: marmad
author_rank: Super Contributor
timestamp: May 24, 2013, 12:07:42 am
content: Quote from: ivan747 on May 23, 2013, 11:51:59 pmBut Agilent calls it 'dead time' - R&S calls it 'blind time'. If you then take it literally, R&S seems more accurate.

author: onlooker
author_rank: Frequent Contributor
timestamp: May 24, 2013, 12:36:17 am
content: QuoteI did some tests with freq counting the trig out and the pulse+ramp method.Yes, the matter is not as simple (at least for 7102). Generally, for stable showing waveforms on the screen, the frequency counting of the trig-out always showed a rate around from 18 to 27Hz independent of the the memory depth.On the other hand, the pulse+ramp method, generally, evaluated the upd rate to about 100Hz for the timebase in the range from about 50us/div to 5ns/div.The seemingly strange thing was that, at the flicking threshold point, the freq counter always showed a freq about the same as the pulse+ramp method evaluated to (about 100Hz).My guess is that the time interval between the 1st pair of trigger events after a long quiet period is not the same as with continues/uniform triggering. I am not sure if this just applies to 7102, or also to other scopes.I think more evenly placing the pulse and the ramp may improve the method for getting the number for continuous triggering. Then, more efforts are needed to avoid the aliasing effect.

author: marmad
author_rank: Super Contributor
timestamp: May 24, 2013, 01:20:59 am
content: Quote from: onlooker on May 24, 2013, 12:36:17 amWell, strangely, I've been hearing about measurements (using a different technique) that suggest perhaps the Owon's wfrms/s rate (at small sample lengths) is higher then what has been previously believed.QuoteThat's possible. OTOH, it's also possible that the Owon's Trigger out is completely inaccurate as a measure of the wfrm/s rate - but instead is limited by the refresh rate of the LCD or something else.It would be good if someone could test it thoroughly using a technique that didn't rely on the Trigger out - as I've done with the DS2000.

author: ivan747
author_rank: Super Contributor
timestamp: May 24, 2013, 01:44:06 am
content: Quote from: marmad on May 24, 2013, 12:07:42 amWell, it depends on who's the blind guy. Agilent thinks you are the one blinded, so they take the points captured and not being not shown on the screen as part of the blind time. R&S believe the blind time is when the scope cannot "see" the waveform i.e. cannot capture it.

author: rf-loop
author_rank: Super Contributor
timestamp: May 24, 2013, 09:33:24 am
content: Here is result with Owon SDS7102V V2.8.3I have now repeated all tests more and also done some (many of) checking tests with other equipments and agen and agen result is same.Tests with other settings are under work.It trigs, and display, two pulses what have 2.35ms time difference. If time is less, this second pulse fall to blind time period and not trigged. Calculated from two pulses time difference, speed is 425 displayed wfrm/s.It is unexpected result!It need confirmation.So I ask if someone have trusted signal sources and can do corresponding test and peer reviews for this result.Owon trig out can not use at all for this measurement.Trig out can use only with very slow speed things. Example set scope to single mode and go to drink coffee... trig out can ring bell after scope have trigged

author: tinhead
author_rank: Super Contributor
timestamp: May 24, 2013, 12:42:16 pm
content: Quote from: rf-loop on May 24, 2013, 09:33:24 amindeed, 425 wfms/s is good result, who knows, maybe the DSO core is that fast but the trigger out only synched to UIrefresh rate (which actually Owon confirmed).

author: rf-loop
author_rank: Super Contributor
timestamp: May 24, 2013, 03:31:38 pm
content: Here tested with 1k, 10k, 100k, 1M and 10M memory depth.If do some calculations, it is also good to note used sampling speeds.If look 1us.1k memory there is 50Msa/sMemory lenght is 20us. (and trigger position is half way)After first trig, it takes minimum 2350us before it can trig agen.Visible area is 15 div horizontally and capture lenght is 20div (for oscilloscope and human blind time calculation)10M memory, there is 1Gsa/s.Memory lenght is 10ms (and trigger position is half way)After first trig, it takes minimum 15.2ms before it can trig agen.Visible area is 15 div horizontally and capture lenght is now 10000 div (for oscilloscope and human blind time calculation)Here attached new test (checked previously made and added all memory depths.

author: marmad
author_rank: Super Contributor
timestamp: May 24, 2013, 04:26:21 pm
content: Quote from: rf-loop on May 24, 2013, 03:31:38 pmI don't know, rf-loop. According to your table, the Owon is doing 80 wfrm/s with 10MPts @ 50ns/div. My DS2000 does 142 wfrm/s with 14MPts @ 50ns/div. Having used both DSOs, the Rigol feels more than just 75% faster - it feels a few times faster. I know this doesn't prove anything - and I could certainly be wrong - but I'm just wondering about those figures.It would be good to get confirmation using a different technique to measure.

author: rf-loop
author_rank: Super Contributor
timestamp: May 24, 2013, 05:07:09 pm
content: Quote from: marmad on May 24, 2013, 04:26:21 pmAs I write, this test show what was smallest delay time between 2 pulses what give reliable repeatable trigger and visible signal in this test configuration.This is only exact test data (including some natural small errors in accuracy) and it can repeat as many time want where ever workshop with used equipments and method. Also here was other people who also check that I have not made any decimal point type or other trivial error. Just becouse this result was so unexpected.And also becouse this unexpected data, I ask if someone other can do some kind of same test with this "marmad" published very nice method (adapted some amount)https://www.eevblog.com/forum/testgear/year-2013-oscilloscope-choices/msg223144/#msg223144I do not want to take any other position on the basis of the actual real continuous displayed wfrm / s in all.However, in this test, now that I have it continued and repeated, showing that the OWON is in some way more forward than it has been in the habit of common thinking.Note: OWON Trig Out ??connector has no meaning in this case. (yes it can maximum about 35Hz but it is not true trig out... but also faster speeds it can draw signal to TFT related to trigger set position + around over 2us delay and other funnies... ) It is not at all this kind of "trig out" what we normally think and specially, nothing to do with these trig outs what are in professional true oscilloscopes (analog oscilloscopes).

author: jpb
author_rank: Super Contributor
timestamp: May 24, 2013, 08:04:06 pm
content: It is interesting in the light of the discussion on edge triggers in this thread that Iwatsu have added both types of Edge Triggers in their latest scope (a development of the WaveJet), though their OR edge trigger seems to be designed to operate on more than one channel:Versatile trigger functions offer the best suited trigger for each type of signal[Edge ALT] Trigger allows alternate rising edge and falling edge triggering[Edge OR] Trigger allows edge triggering of signals for multiple channelsPattern Trigger allows triggering using complex patterns of logical signals Trigger allows triggering on signal dropouts, etc.

author: onlooker
author_rank: Frequent Contributor
timestamp: May 25, 2013, 04:25:27 am
content: QuoteI believe even if these numbers about Owon SDS7102 are correct, they may not imply that the average waveform update rate under continuous triggering are as good.I tried the n-pulse burst method that jpb proposed (either with persistence+FG single wave, or no persistence+camera). Though not conclusive yet, what I found was: As I guessed earlier, the wait time required between the 1st pair of trigger events after a relatively long quiet time (~0.1s) is indeed much shorter than the wait time required between subsequent triggerings. To do the test one does not even need to adjust much the time interval between the pulses in the burst. One needs only select a time interval that is faster than the max wfrm rate of the scope and counting the misses.For example, for an 11 pulse burst evenly spaced by 22ms (wfrm rate=45Hz) or 11ms (wfrm rate=90) running at one burst per second, the 1st 2 pulses always trigger, the subsequent pulses in the burst start to miss. By counting out the missed pulses, for both cases the average wfrm rate consistently come down to the same disappointing number, about 27 triggerings per second showing on the screen. With persistence on, it was worse. At this point, even if the hardware can do better, if it can't be shown on the screen, could the user still benefit from it?Maybe the new version can do better. But I really like to see someone test the max upd rate under continuous triggering.The scope setting for the tests: 1k points, normal sampling, normal trig, 500ns/div

author: rf-loop
author_rank: Super Contributor
timestamp: May 25, 2013, 08:21:28 am
content: Quote from: onlooker on May 25, 2013, 04:25:27 amYes.Numbers are exatly correct. (but including natural accuracy errors in signal source and also in many cases it start find delayed pulse B trig smaller delay but not always. I have rised delay time from this "sometimes trig to B" until it trigs always - exept time when scope do something and it is "thinking" something and loose this trig to pulse B. It looks like periodically but shortly scope do something what need more time - example storing current settings)This, what you say, is also reason why I did not write waveforms/second table - and I also recommend no other do it. As long as this table is just as it, it is ok.Totally other question is perhaps more interesting.For clarify:This is NOT for Owon:Trigger out based displayed waveforms per second tables. Aka "wfrm/s" tables.Trigger out can easy measure. But how it is proofed that every these events are always really displayed and what include one displayed waveform... 20 point of data? or something other. Where I can find tests with proofments every counted (from trigger output) trig event really mean displayed single waveform on the screen via diplay memory. This whole wfrm/s case is full of not clear things. Read big brands material and then I ask, is it really clear. No, it is not. It looks that even Agilent or R&S have different thinking what is blind time etc... I have not seen any common standard what is exact definition of wfrm/s. Some talk captured waveform, but how long data.. some talk displayed waveforms but do not specify what is displayed.. ten pixel or 1kpoints data in every "waveform".Where are exact specifcations. Yes, I have read more than just some years Hewlett Packard and destroyed "Hewlett Packard" (tca "A-gi-lent") materials, Tektronix, R&S and so on. I can tell. I do not know what is real and exact general and uniform definition of wfrm/s. In analog scopes times I know it well. Perhaps it is only my problem becouse just I do not understand but I afraid I'm not alone with this.Who can proof me that in all cases example every trig out means also real displayed waveform and how much data it contain.One manufacturer long time ago tell that there is max 2000 waveforms per second. I can see barely just over 20. If there was 2000 waveforms captured per second where they aredisplayed.Perhaps it need some magic camera... normal Canon can not see them and my eyes can not see these.(generate fast changing signal and install camera taking picture with enough long shutter time or use example very fast video camera and then count what is really displayed. - this is perhaps good idea for Dave - take some amazing method for detect real displayed wfrm/s and remove mystery woman "wfrm/s" pants. However, I am afraid that not everyone will like it - I mean, some of the prominent manufacturers.)Be careful with these pulse or other methods calculated wfrm/s ("displayed waveforms per second") values and even with trig out methods concluded. Trig out counting tell exactly how many trig out events there can find in time period and this number is of course true, it can measure from trig out. What other things it really tell - who knows.For clarifyThis is agen for Owon:Here also two very old test images (Feb. 2012). (also I wonder this other image lines, there is many just near each others, then some have bigger distance and all these images with 10M memory in use. around 38truedisplayedfull waveformsper second and all these separate captures are 10M lenght but of course in image there is only very very small part of every capture.)

author: onlooker
author_rank: Frequent Contributor
timestamp: May 25, 2013, 10:24:31 am
content: I guess there is a misunderstanding about my last post due to not being explicit enough.For all tests I did there, NO trig-out was used. That is, trig-out was irrelevant. The discussions were based on what were displayed on the screen determined either by using a camera (shutter speed set to a little over 0.5s) or by placing the scope in the persistence mode. I will try to put some pics up later.

author: rf-loop
author_rank: Super Contributor
timestamp: May 25, 2013, 10:32:24 am
content: Quote from: onlooker on May 25, 2013, 10:24:31 ambtw, there is bug in persitenceAlso added old images to my earlier post

author: marmad
author_rank: Super Contributor
timestamp: May 25, 2013, 11:10:42 am
content: Quote from: rf-loop on May 25, 2013, 08:21:28 amWell, that was one of the points of my video - to demonstrate another method to see if the DSO is doing what it says it's doing. I think for my DS2000 (unless Rigol is not telling the truth about what the Edge trigger is doing, etc), the video shows that the Trigger out is at least following what is happening on the DSO display.But I agree there should be more information: manufacturers should publish baseline stats, or - better still - there should be a waveform counter on the screen (along with sample rate and length), so that we, the users, can decide - given all the information - which time base setting (and it's associated sample and waveform rates) would best suit what we're trying to do.QuoteI understand your point, but your figures are missing some information:Tests with Air Force pilots have shown that they could identify a plane on a picture that was flashed for as little as 1/220th of a second (i.e. make a distinction between a non-airplane shape and an airplane shape) - so there is evidence to support the theory that humans can identify discrete pieces of information in something close to ~1/250th of a second. So this would imply that wecouldnotice a glitch that appears and disappears in the space of what is currently around the fastest refresh rate of an LCD: approximately 240Hz (I don't mean in DSO LCDs yet - I just mean in consumer goods).More importantly (given current DPO technology), according to research, we can identify ~100 levels of intensity. So the obvious reason to have intensity grading is to increase the amount of information wecouldperceive on the DSO screen per second by a factor of ~100.

author: tinhead
author_rank: Super Contributor
timestamp: May 25, 2013, 11:12:32 am
content: Quote from: rf-loop on May 25, 2013, 08:21:28 amyou can take even the light speed camera, the display is refreshing with complettly different refresh rate than the data refresh in sample buffer. Take TDS700, enable DPO/InstaVuand you will see persistently lot of events, but when you capture them with cam, you will not see 400k wfms/s (even if you can measure such value on trigger out).Even if something has been captured once, and saved for some time into DPO buffer, it does not means you will see it ALWAYS on screen, you might miss itdue the buffer/screen refresh ration. Sure, you will see programmed glitch at last each every second (which is in my opinion still the second best way to measure wfms/s),but random glitch is something complettly different. The equation in fw can as well eliminate some glitches when there are lot of them (as the persistency/cumulative occurrence is finite).There is as well sometimes problem with the way how DSO is working. Some manufacturers providing best case data only, where the wfms/s is not continuesly stable buta avg. from bursts. That's not 100% ok, but yeah, where is the wfms/s internation standard? I remember LeCroy had such models (don't ask me for numbers),probably others as well. When looked on the available videos (example Instek), i can clearly see windows in trigger out where the difference between events is not equal.This is giving always a chance that you miss event.Hantek is for sure doing this (from my observation, measurments, FPGA readbacks), FPGA seems to capture data into DPO-like buffer, where ARM firmwareis reading (with best case 50x slower rate of course) the data into second buffer. Here the persistency will be calculated (i have no idea why Hantek decided toshow only the DPO-like persistency in run mode and not stop mode, anyway, that's different story), and based on UI settings the thread might run faster orslower, which can (and it does) cause skip on data readback from FPGA buffer. When you run tests with preprogrammed glitch, you can clearly see peaks in whatcaptured. I don't mind, at time of development that was first chinese DPO-like scope with good wfms/s rate*, but i would prefer to have continuous rate.*there are as well Rigol CA models, but they work complettly different, they using two FPGAs (like the DS2000 models, however they don't have external RAM).Afaik (based on report from someone else, i don't own CA model) they can provide continuous 2000wfms/s.

author: jpb
author_rank: Super Contributor
timestamp: May 25, 2013, 11:14:28 am
content: One thing about the WaveJet history mode is that you know that it has captured all the waveforms because you can run through them individually. Though you do have to assume that the time stamp is accurate (as for as I can ascertain it is very accurate).The drawback is that all the knob twiddling has knackered my wrist (in conjunction with pushing a heavy trampoline), I'm now having to type with my wrist in a splint, so no more experiments for me for a little while!If I ever manage to get a waveform generator I'm looking forward to trying the method of this thread (but with two pulses) to see how the results compare.

author: marmad
author_rank: Super Contributor
timestamp: May 25, 2013, 11:23:49 am
content: Quote from: jpb on May 25, 2013, 11:14:28 amYou can do the exact same thing on the Rigol - and I assume other scopes with segmented memory as well; e.g. Agilent, Instek, etc.

author: rf-loop
author_rank: Super Contributor
timestamp: May 25, 2013, 11:38:43 am
content: Quote from: tinhead on May 25, 2013, 11:12:32 amYes - (and no).I do not mix TFT refresh time and waveform capture rate.Also this Owon example simple proof that also it can capture new waveform much more fast than TFT update period.This is now too much simplified but:If scope acquire to "virtual phosphor" all claimed captured waveforms. They are there.Then sometimes they are transferred to TFT. This TFT image refres rate have nothing to do with waveforms captured per second.Now, example if there 100 waveforms captured to "virtual phosphor" memory and then come TFT tranfer.. they appear visible on TFT. Example 50 times per second. Now if I take photogtraph from this one just updated TFT screen there need be visible these 100 waveforms (if there is enough differencies between these captures so that they use different diplay pixels). Now If I keep shutter open and take example all 50 TFT frames. And if signal have enough changes I need (in theory) Find 5000 waveforms from this 1 second image. (display rsolution perhaps can not show these but every 1/50 frame need show what is collected (captured) in this refres time to "virtual phosphor".(of course this 1/50 update rate is just imagined example). Perhaps you remember this one old test image from Hantek screen... I have it somewhere but can not find it now.Becouse it is "displayed waveforms per second"(Of course now there can be also brightness gradiend what add information... just like real phosphoir work but this is other thing)This technique to measure waveform update rate is other question.Example if I now calculate wfrm/s table using these test results, whole table is total bullshit.

author: jahonen
author_rank: Super Contributor
timestamp: May 25, 2013, 11:40:34 am
content: Quote from: marmad on May 25, 2013, 11:10:42 amHuman vision "speed" is difficult to characterize by a simple figure. If you have a suitable "single pulse generator", you can test it by yourself by connecting a led to the generator output. It is possible to see surprisingly short flashes of LED. IIRC, when I tested this some time ago, something like few hundred nanoseconds long flash was perfectly well visible. Of course, the effect is similar than connecting a Jim Williams pulser to a low bandwidth scope, one gets just a small bump on a trace.Regards,Janne

author: jpb
author_rank: Super Contributor
timestamp: May 25, 2013, 12:01:47 pm
content: Quote from: jahonen on May 25, 2013, 11:40:34 amIf you apply such a short pulse to a LED I'd have thought that there would be an inductive effect that would mean that light from the LED was spread over a slightly longer time.

author: marmad
author_rank: Super Contributor
timestamp: May 25, 2013, 12:21:06 pm
content: Quote from: jahonen on May 25, 2013, 11:40:34 amBut the quickest that a trace can first appearand then completely disappearfrom a DSO screen is limited to the refresh rate of the LCD - it can never be smaller than that. So that is the smallest period of time that a DSO can simulate a 'flicker'.

author: marmad
author_rank: Super Contributor
timestamp: May 30, 2013, 11:36:40 pm
content: Quote from: marmad on May 23, 2013, 11:21:52 pmHa, ha... just a coincidence?A week ago (May 24th) I wrote the above post, pointing out the fact that Agilent and R&S have different definitions of dead (blind) time - meaning that their calculations could provide different blind time percentages given the same set of data. I pulled info from the oft-quoted Agilent document, "Evaluating Oscilloscopes for Best Waveform Update Rates", published in 2011, that contains this graphic, illustrating Agilent's definition of dead time (at least their published definition up to a week ago):Well, exactly 5 days after that post (May 29th), Agilent published an online article called,"What is waveform update rate and why does it matter?", which includes the following graphic - which appears to 'refine' their definition of dead time into two sub-sections: "Effective"dead time and "Real" dead time - effectively fixing the disparity between their calculations and R&S (if you use "Real" dead time for calculations):You're welcome, Agilent! Now where's my free test gear?

author: jpb
author_rank: Super Contributor
timestamp: May 31, 2013, 09:45:04 am
content: Presumably if you are looking for glitches it is the display window that matters.The difference becomes significant at slower time bases where the real dead time is trivial compared to the acquisition time.At slower time bases it doesn't matter much for glitch hunting because the total dead time is only a small percentage, but it does mean that if you're trying to estimatethe real dead time by measurements at slower time bases you need to know how much extra is captured (or buffered).In trying to translate my waveform update rates into a dead time (real dead time) I've concluded that the WaveJet probably has a buffer of 520 points when it captures 500 points for display. This is a slightly odd number (I expected 512) but it is the number that seems to make sense of the measurements at different time bases.

author: marmad
author_rank: Super Contributor
timestamp: May 31, 2013, 10:23:54 am
content: Quote from: jpb on May 31, 2013, 09:45:04 amIf by 'looking' you mean literally with your eyes, then yes. But I could capture, for example, 8128 segments of acquisition time (while having a much smaller display window) and analyze them after the fact for glitches.

author: jpb
author_rank: Super Contributor
timestamp: May 31, 2013, 12:12:03 pm
content: Quote from: marmad on May 31, 2013, 10:23:54 amThat is true of data that is saved, but with most scopes they save only data that is within the display time frame. I think there is some data that is captured in the sense of being sampled into a buffer but is not saved into longer term memory. This comes back to our previous discussion on the extra 2%. For example the WaveJet displays 1024 captures at once which you can go back through (segmented memory). But each of those individual captures contain up to 500 sample points, whilst I think that the buffer is more like 520 points. The extra 20 points are captured but you can't look at them as they are not transferred to main memory.Given that there must be some variability in time taken to trigger and half-a-screen of pre-trigger data is needed there must be more in the buffer than is actually then saved or displayed. This extra data is captured at the sample rate regardless of how fast the processing and is, I think, why blind times rise for the slower time bases.

author: marmad
author_rank: Super Contributor
timestamp: May 31, 2013, 02:13:16 pm
content: Quote from: jpb on May 31, 2013, 12:12:03 pmLonger term memory? Maybe you're confused a bit based on the way your Wavejet is doing things, but virtually every modern DSO work's in pretty much the same way. The acquisition time of a DSO is always either the display window (as Agilent calls it) or the sample length - whichever is longer in real-time. For example, when my sample rate is 2GSa/s, my DSO is grabbing a sample every 500ps. If I have the sample length set to 140k, it takes the DSO 70us to fill it. If my time base is set to 10us/div, the display window is 140us (100us x 14), so the DSO halves the sampling rate clock (or, like the Agilent X-Series, throws out every other sample) to match the sample length to the display window time - thus making my acquisition time 140us. But if my time base is set to 10ns, the display window is only 140ns, but the DSO is still capturing 70us - so 70us is my acquisition time. If I stop the DSO at any time - I can 'zoom' out and see (or analyze) all the samples.

author: jpb
author_rank: Super Contributor
timestamp: May 31, 2013, 03:54:03 pm
content: Quote from: marmad on May 31, 2013, 02:13:16 pmYes, the WaveJet operates differently. If I set 500k memory and a time base of say 10nS/div it will only capture the 200 points (at 2GS/s) and will display up to 1024 such captures i.e. the memory is the maximum allowed, it doesn't carry on beyond a screen full. (Or rather it does carry on but in a segmented fashion.)So it determines the size of the pre-trigger buffer from the time base setting. You can zoom in but not zoom out.Of course, if you're just capturing data for post analysis then the methods are equivalent - you either set the segment size directly or set it by setting the time base and maximum allowed memory.If you're trying to see glitches on the screen, the most common way to look for them I would have thought, then you're not going to be zooming out anyway.

author: marmad
author_rank: Super Contributor
timestamp: May 31, 2013, 05:06:35 pm
content: Quote from: jpb on May 31, 2013, 03:54:03 pmAbsolutely - especially if you're not necessarily expecting them - thus the reason for desiring faster waveform update rates: to have better odds of seeing them when they're intermittent or unexpected.There really isn't much point to using large sample lengths at time base settings < ~1us/div (for a 2GSa/s DSO), unless you have a specific reason for capturing lots of extra samples after (or before) the trigger point. But of course, at time base settings greater than that, it's a whole different story because of sample rates.

author: illyesgeza
author_rank: Contributor
timestamp: June 01, 2013, 09:17:12 am
content: How To measure the refresh rate of a DSO.I tried on a siglent1102select 1Gs sampling rate(on siglent is 50nS/div)select trigger on rising edgeselect one channelso you have 40960 samples (total 0.04096 miliseconds)you have to generate two (and only two!!!) pulses with a controlled amount of timebetween themthe two pulses must not be equal in widthI genarate the first 250nS and second 500nSwhile the time between them is less than the refresh time you'll see the firstpulse in the middle of the screenwhen the time is equal or greater than the refresh time you'll se the secondThat's why the width must be different (to make the difference between the firstand the second)I have genarated the pulses with an Atmell micro controller runing at 48MHz clockThe narrowest pulse you can generate is 250nSexample:move portbit,1move portbit,0 ;first 250ns pulse _|-|_call delay(x); //this must be variablemove portbit,1move portbit,1move portbit,0 ;second pulse _|--|_//that's allif you try this with x = 20mS you'll see the first pulseif x > 30mS you'll se the secondSo I think that the refresh rate is around 30 - 50HzThat's for 1Gs sampling ratefor slower rates the refresh rate will be lower

author: marmad
author_rank: Super Contributor
timestamp: June 01, 2013, 12:22:34 pm
content: Quote from: illyesgeza on June 01, 2013, 09:17:12 amYes, this is posted aboutearlier in this thread.