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

[marmad]

and this is exactly what HanTekway is doing as well, the single shot on DS2000 looks to me like it does exact the same
as well too.

I don't know what you mean by this - what are expecting the single shot to look like? IMO, it looks exactly as it should.

So probably in run mode DS2000 is simply triggering twice (on both edges, which was exactly what i
requested from Hantek as a fix for their current " both edges" implementation), which (i guess) could explain why on Rigol
one edge disapears when reached the blind time window.

I 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 in the previous diagram. 

[marmad]

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.

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

[Harvs]

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.   

Results I got, DS1052E hacked to 1102,

500ns/div 36 or 37 wfms/s
50ns/div 39 wfms/s

[ivan747]

@marmad

It's possibly the firmware. I have firmware 00.04.00
I 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.

[ivan747]

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.   

Results I got, DS1052E hacked to 1102,

500ns/div 36 or 37 wfms/s
50ns/div 39 wfms/s

Can you please post your firmware version? The fact you hacked it tells me it is 00.02.something

Further 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: triggered
• 1st cycle falling: no trigger
• 2nd rising: no trigger
• 2nd falling: trigger
• 3rd rising: no trigger
• 3rd falling: no trigger
• 4th rising: trigger
• 4th falling: no trigger
• 5th rising: no trigger
• 5th falling: trigger

Is you want me to go even slower I can hook up a pot to this oscilloscope. 

[marmad]

Results I got, DS1052E hacked to 1102,

500ns/div 36 or 37 wfms/s
50ns/div 39 wfms/s

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

[darrylp]

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.   

Results I got, DS1052E hacked to 1102,

500ns/div 36 or 37 wfms/s
50ns/div 39 wfms/s

@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 ;-) )

[Harvs]

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.

[Harvs]

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.   

Results I got, DS1052E hacked to 1102,

500ns/div 36 or 37 wfms/s
50ns/div 39 wfms/s

@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 ;-) )

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

[ivan747]

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.

Exact 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)

[marmad]

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.

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

[marmad]

Exact same settings, this is what I see (infinite persistence on so you can figure it out).

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

[ivan747]

Exact same settings, this is what I see (infinite persistence on so you can figure it out).

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

Fair enough, turned everything off, persistence, counters, measurements, channels, Sinx /x interpolation and ejected the drive. Same effect. There's something different about our units.

[marmad]

Fair enough, turned everything off, persistence, counters, measurements, channels, Sinx /x interpolation and ejected the drive. Same effect. There's something different about our units.

Yes, it really sounds as if Rigol, for some reason, might have changed the behavior of the Edge trigger in your version of the firmware.

[ivan747]

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.

[ivan747]

Fair enough, turned everything off, persistence, counters, measurements, channels, Sinx /x interpolation and ejected the drive. Same effect. There's something different about our units.

Yes, it really sounds as if Rigol, for some reason, might have changed the behavior of the Edge trigger in your version of the firmware.

Should be interesting to see if the waveform acquisition rate changed with the update as well. Let's find out!

[Harvs]

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.

[Harvs]

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.

[Harvs]

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.

[marmad]

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.

Nice find!! I'm rather amazed no one has located this before. 

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.

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

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.

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

[Harvs]

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

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

[Harvs]

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

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

[marmad]

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

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

[eKretz]

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/s
100ns - 230,000 wfm/s
200ns - 200,000 wfm/s
500ns - 120,000 wfm/s
1µs - 60,000 wfm/s
2µs - 30,000 wfm/s
5µs - 11,200 wfm/s
10µs - 6,000 wfm/s
20µs - 3,050 wfm/s
50µs - 1,200 wfm/s
100µs - 625 wfm/s
200µs - 325 wfm/s
500µs - 125 wfm/s
1ms - 62 wfm/s
2ms - 25 wfm/s

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

[alank2]

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.

Yes, this is a known (and published) technique    I was trying to come up with something easier.

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