Simple Technique to measure Waveform Update Rates: DSOs w/either Edge Triggering

[Deckert]

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.

Right, 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

[Harvs]

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.

Right, 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

Your 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.

[onlooker]

Yes, this is a known (and published) technique

Ok 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.
 

[ivan747]

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.

[jpb]

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 frequency
dependent 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).

[marmad]

This does seem a good approach only frustrated by the fact that most scopes are designed to trigger on only one type of edge.

Sorry, 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, do it.

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 implement alternate Edge triggering - which is very similar to Pulse triggering; another standard trigger type offered in most DSOs - but not either - which is not similar to other standard triggers.

Edit: I've been updating this with more manufacturers that make DSOs with either Edge triggering as I look through manuals.

[jpb]

This does seem a good approach only frustrated by the fact that most scopes are designed to trigger on only one type of edge.

Sorry, but I'm think you're wrong with this deduction. 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 and GW-Instek DSOs both, in fact, do it.

So that means - with info gathered so far - we have Agilent, GW-Instek, and Rigol making scopes that trigger on either edge - Hantek, Siglent, and LeCroy making scopes that don't (Owon I'm not sure about). So which group designs more DSOs?

To me, the strange thing is that DSO manufacturers would instead implement alternate Edge triggering - which is very similar to Pulse triggering; another standard trigger type offered in most DSOs - but not either - which is not similar to other standard triggers.

For 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.

[marmad]

For 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.

True - 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. 

The present experiment aside, in general the ability to trigger of either edge is not something that is often used I would have thought.

Well, 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.

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.

As mentioned before, this can be easily accomplished with a standard Pulse Width trigger - so having alternating Edge triggers (as Hantek, Siglent, etc. offer) is rather unnecessary (and a waste, IMO). OTOH, triggering on either edge can't easily be accomplished with another trigger type.

[ivan747]

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.

Actually, we only need square waves, and we only need sub-MHz bandwidth, so you could try to program a micro controller to do this.

[marmad]

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.

Well, 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:

[Harvs]

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.

Well, 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:

Yep, 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.

[marmad]

Yep, 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.

But 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.   

[Harvs]

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.

[marmad]

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.

Great... thanks! 

[jpb]

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.

Well, 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:

Interesting 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.

[marmad]

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...

No, they mean precisely 14000 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).

[jpb]

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...

No, they mean precisely 14000 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.

The 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%.

[ivan747]

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.

[marmad]

The 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 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? 

[marmad]

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.

@ivan747: Well, I'm not 100% sure that the DS1000E series allows either rising 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 frequencies doesn't stop your DSO from triggering on both edges (and produce a stable, non-moving waveform), then the DS1000E series is doing alternating Edge trigger - instead of either Edge - and this technique won't work.

[marmad]

The 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.

When 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 - not 14,680,064 points (14 * 1,048,576) - since in the latter case, the blind time would be negative.

[jpb]

The 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 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. And why check bits? Can't the FPGA just decrement to zero? 

I 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.

[marmad]

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.

The 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 sample AND display 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.

[tinhead]

As mentioned before, this can be accomplished with a standard Pulse Width trigger - so having alternating Edge triggers (as Hantek, Siglent, etc. offer) is really unnecessary (and a waste of a possible extra feature).

nah, alternating trigger is very usefull thing (even if costs DSOs postprocessing time to switch between channels), maybe
even more usefull than dual edge trigger. On the other side is good to have all of them.

If anyone uses this technique to finally, once and for all, measure the waveform update rates of the HanTekway DSO5000 series,

the latest HanTekway firmware (actually last 5 or so) supports dual edge trigger. However the implementation is not in DSO
core (so not in FPGA) but in UI (ARM firmware), which means it does nothing else than simply re-arm trigger with different
edge value. In principle dual edge triggering is nothing else, but in "DSO" part of the firmware, not after all in the let's call
it 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 the
match 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") between
10Hz 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 firmware
seems 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 data
is 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 fastest
timebase), when i change timebase i can clearly see difference, e.g. at 2us/DIV avg. 1236 waveframes or at 20ns/DIV only
513 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, this
is only what i assume from what i see on FPGA or saw when comparing to TEK

https://www.eevblog.com/forum/chat/hantek-tekway-dso-hack-get-200mhz-bw-for-free/msg174242/#msg174242

But still, it would be nice if someone with Hantek/Tekway/Voltcraft and dual channel AWG/Signal-gen could use the different
method and calculate wfms/s based on what on UI.

[marmad]

nah, alternating trigger is very usefull thing (even if costs DSOs postprocessing time to switch between channels), maybe
even more usefull than dual edge trigger. On the other side is good to have all of them.

You'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.

I've tested it anyway, nothing catched (no blanks, stops, what so ever - except by 30/40/50 sometimes flickering due the
match to selected display refresh rates).

Again, 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 on every edge - but alternate edges (it's skipping potential triggers). From what I can tell of the Hantek, it does NOT do every edge.