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

[marmad]

Edit: As mentioned in later posts, I had assumed that most DSOs could be set to Edge trigger on either (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 on alternate Rising and Falling edges.



If you're not sure if your DSO supports every Edge, you can test very quickly by setting it to 5ms/div, then sending it a sine 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.

[marmad]

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!

[jpb]

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 generator
a series of increasing pulses could be used - set a burst of n pulses and count how many are captured.

[marmad]

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 generator
a series of increasing pulses could be used - set a burst of n pulses and count how many are captured.

No, this technique is MUCH simpler than that: you can measure waveform update rates of any DSO 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.

[jpb]

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 generator
a series of increasing pulses could be used - set a burst of n pulses and count how many are captured.

No, this technique is MUCH simpler than that: you can measure waveform update rates of any DSO in minutes without any special waveform generator (you can even use a PC sound card).

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

[egonotto]

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 Regards
egonotto
 

[marmad]

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

Really? Wow, I just thought that was one of those things that was standard on every DSO - it existed on the cheap DS1052E I had.

[marmad]

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 Regards
egonotto

Hi egonotto,

I will look through the Hantek manual to see if there is an equivalent triggering method you can use.

Mark

[Deckert]

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!

This 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

[marmad]

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

A bug in the Rigol firmware? I'd say a bug in the Siglent/Atten firmware - unless your trigger setting specifically states Rising THEN Falling edge. My DSO manual states Rising OR Falling 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.

[Deckert]

A bug in the Rigol firmware? I'd say a bug in the Siglent/Atten firmware - unless your trigger setting specifically states Rising THEN Falling edge.

 

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

[Deckert]

So it appears I made a mistake in thinking that the ability to select Edge Triggering with both a Rising or Falling Edge was standard on cheap DSOs. The Rigols seem to have this setting - but the Hanteks and Siglent/Attens don't seem to (they have what just appears to be a different type of Pulse Trigger).

Not 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

[marmad]

Mark, you're always so serious!

Yeah, 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 represents either slope - not both.

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.

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

Again - the operative word is OR - not AND. 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?

[marmad]

@deckert - Is your Siglent able to use the operator <> (NOT equal) when using either Pulse or Slope Triggers?

[Deckert]

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

No worries! (like the Ausies say)

But if you notice in the video the icon that Rigol uses for the menu choice - it clearly represents either slope - not both.

I hear you - the icon on the Atten is similar ... i.e. it uses \ or / or X - see screenshot.

Again - the operative word is OR - not AND. 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?

Maybe I'm not understanding you here - it does trigger 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

[Deckert]

@deckert - Is your Siglent able to use the operator <> (NOT equal) when using either Pulse or Slope Triggers?

Hmm, does not look like it. For positive and negative pulses I can see <, > and =, but not <>.

--deckert

[marmad]

I hear you - the icon on the Atten is similar ... i.e. it uses \ or / or X - see screenshot.

No, the icon on the Rigol is different: look at the attached image.

Maybe I'm not understanding you here - it does trigger 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?

Yes - 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-triggers anytime with 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!

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!

Well, I'm testing some other possible alternatives.

[onlooker]

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.

[marmad]

@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

[marmad]

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.

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

[onlooker]

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.

[Harvs]

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/s
200us/div (1Msps) ~= 23wfms/s
100us/div (2.5Msps) ~= 31wfms/s

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

[onlooker]

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.

[marmad]

In the video, when I use Edge Trigger on Rising OR Falling 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 Rising AND Falling edge to trigger, it seems to me that when the incoming waveform frequency reaches that same point - your DSO will STOP triggering (WAIT in upper corner).

Is this not correct?

Nevermind... up too late last night 

[marmad]

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.