Trying to use frequency counter to read WFM/s from MSO5000. Need help.

[ballsystemlord]

Hello,
Recently, Dave made a video about the KS HD3 oscilloscope and compared it to the R&S MXO 4 series. I wanted to replicate his test to see how my MSO5000 scope compares in it's WFM/s rate to the above two scopes. During my testing, I observed some odd behavior. I thought about asking how this works in the HD3 thread, but I didn't want to hijack the thread so I'm spinning up my own.

@Dave (I said), I just thought about this, but doesn't the HD3's reading it's own trigger invalidate the WFM/s test?
Like, if the scope is in it's "dead time" it's neither reading the trigger pulse nor outputting it. Therefore, according to the scope, it's trigger rate is always 1M+ WFM/s.
Maybe I'm not understanding something?

I used the frequency counter function, not triggerign from it's own trigger output. (Dave replied.)

Now I setup my MSO500 to use it's own frequency counter. In the photo below, you can see my setup (I did try it with an official Tek 50 terminator. That doesn't change anything.) I get the result of 41.75Khz. According to my calibrated GW Instek 9061 DMM, that's dead wrong. The update rate is actually ~19Khz. I also got roughly the same result with an out-of-cal BK precision 391A. So this isn't an artifact of the GW Instek meter.

I tried turning the counter off and on, setting the scope back to default settings, and I found that the frequency that the scope reads is either the above 41.75Khz, or ~15Khz, seemingly randomly switching between the two. I tried turning channel 4 on, but that just resulted in the counter not working at all; even after turning off and then back on the frequency counter.

To be clear, I'm fully aware that the HD3 and the MSO5000 are totally different beasts. But I'm still really lost here as to why this isn't working on the MSO5000 but apparently works just fine on the HD3.

Can anyone explain what's going on?

Thanks!

PS: I'm happy to perform any further tests as you see fit to narrow down what's going on, provided it's within my capabilities to do so.

PPS: If it helps, the trigger output of the MSO5000 is 3.3v logic. With a 50ohm terminator attached the voltage falls so far that my GW Instek 9061 cannot read the frequency. It's capable of reading up to 1.2Mhz accurately (oscilloscope wave gen into DMM). It makes no difference if the terminator is feed-through or a 50ohm load attached to a BNC tee.

[Someone]

You really need another scope to check the "trigger" (acquisition) out waveform. It is usually pluse trains with inconsistent frequency, that will confuse many "frequency" measurements, and unscrupulous manufacturers use the peak rate of the pulses as their spec.

[ballsystemlord]

You really need another scope to check the "trigger" (acquisition) out waveform. It is usually pluse trains with inconsistent frequency, that will confuse many "frequency" measurements, and unscrupulous manufacturers use the peak rate of the pulses as their spec.

When setting the "Gate time" of my DMM I did notice that. I've seen others, on YT, use dedicated frequency counters to do the same measurement I'm doing with my DMM. So, I assumed my DMM was good enough for the job.

Unfortunately, I have only one oscilloscope at this time. Although I could go for one of those really cheap handheld scopes from china, I think I'm better off waiting till I could afford better equipment.

[Sensorcat]

Use the frequency measurement from the measurement menu instead. It offers several parameters to customize the measurement and address the issues you see with the counter. This includes the possibility to average, which is useful because you don't want the peak rate, as Someone pointed out. But it's definitely possible to measure this with the instrument itself. I have done that, at least for some instrument settings.

[ballsystemlord]

Use the frequency measurement from the measurement menu instead. It offers several parameters to customize the measurement and address the issues you see with the counter. This includes the possibility to average, which is useful because you don't want the peak rate, as Someone pointed out. But it's definitely possible to measure this with the instrument itself. I have done that, at least for some instrument settings.

I tried what you suggested before, but thought I'd post a picture so you can see what happens. What happens is that I don't get any frequency reading at all.
I set the persistence to 1s, so you can see that what I'm getting is only part of the square wave. In the picture, I'm using the default/auto memory setting.

I tried changing the memory setting from 1Kpts through 100Mpts in increments of 10x per step with the hope of changing the update rate to something the scope could read. I also tried changing the span from 100ns to 50us, without effect (again, tried playing with the memory settings.) I also tried panning the span back and forth without effect.

I'm not trying to say that you're wrong, just that I can't imagine how to do this correctly, in the sense that I get a sane result, or in this case, any result.

EDIT: Forgot to attach photo.

[Sensorcat]

Sorry, it seems that my memory didn't serve me well. I tried to reproduce this, but came to the conclusion that it is not possible and I must have mixed that up with something different.

[Sensorcat]

This morning, I instantly had an idea how it is possible to measure WFM/s with the MSO5000 alone. Not with the measurement function, though.

Since your goal is understanding how it works, it is useful at first to clarify why the measurment function had to fail to deliver the desired result: When the scope is triggered, the acquisition starts, and the TRIG OUT signal provides an edge. During aquisition, no new triggering can happen, and so TRIG OUT does not show more egdes, which would be mandatory for frequency measurement.

So why can the counter produce results sometimes, but inconsistent? Since we do not have implementation details, we can only speculate on this. But an educated guess would be that the gate time of the counter is somewhat independent from the single aquisition. Since the MSO5000 was designed to impress with specs at an affordabe price, not all of its many features are developed to highest usability and reliability. So this 'somewhat' leads to inconsistent results if it does not match the purpose. And since the counter is fully automatic, with no parameters to tweak (unlike the measurement functions), nothing can be done about it on the MSO5000. Other instruments might have dedicated hardware for the internal counter, such that it is really an instrument within the instrument. Consequently, this dedicated hardware could work without the restrictions the MSO5000 has in this regard.

Now the trick to measure WFM/s: Clearly, we need to have more than one trigger event. This becomes possible with segmented memory. This function splits the aquisition memory in a number of parts, such that each part is filled with samples from consecutive tigger events. Each segment gets a time stamp, so we get to know how long these consecutive events are apart.

Starting with power on defaults and nothing connected to the MSO5000, try this:

• Connect output G I to input CH1. You don't need to worry about termination, a <1m coax cable will do without.
• Set G I to sine 25MHz, 5V amplitude.
• Set CH1 to 1V/DIV.
• Set Mem Depth to 1k and timebase to 10ns/DIV.
• In the Utility menu, select Record and turn it on (1st button labeled Record).
• Using the defaults, start recording (press 2nd button labeled Record).
• A window appears, telling what time stamp the last segment had (the first should have zero, but sometimes it is the second).
• Devide the time stamp value by the number of segments, default 1,000, to get the average interval t between trigger events. WFM/s = 1/t.

It is interesting that this measurement does not even use the TRIG OUT signal; the time stamps tell it all. You can play around with instrument settings from this starting point, and observe, as a rule of thumb: The more you ask the scope do do, the lower the WFM rate will be. It is difficult, however, to get readings that match those from a dedicated counter. This is because acquisition is the only real-time function of the scope; it is a computer otherwise, with a lot of tasks in the background, so the results wary from test to test and with gate time. The above measurement seems to provide somewhat faster results than the counter at the same settings, but without segmented memory, probably because some background tasks are suspended during segmented recording. Also, it is not possible to reach the maximum with segmented recording, probably because it requires additional software action itself. I could get to about 165,000 WFM/s with segmented recording. Rigol's claim of up to 500,000 WFM/s is easily verified with a dedicated counter and the settings mentioned in the specs.

[ballsystemlord]

I setup my scope and did the measurements exactly like you suggested. I'd like you to comment on if I got the math right. Your description wasn't 100% clear to me.  The default was 11 frames, which I'm guessing is what you meant by "segments".

I tested my scope this way over 10 times for statistical accuracy in my results. My results are rounded to within the last 3 significant digits. Please note that sometimes I'd get results in seconds and sometimes in us, thus the discrepancy in the data.

00.000067104
00.000066976
15.132
00.000067168
23.02
00.000067072
00.000067008
00.00006704
00.000068288
00.000066912
00.00006704

With the outliers we get an average of 3.468 . 1/(3.468/11) == 3.172wfm/s.
Without the outliers we get an average of 0.000054964 . 1/(0.000054964/11) == 200130.995wfm/s.

Under slightly different settings than you specified above (1K memory depth, 100ns/Div, 500mV/Div, 300ns square wave period, 2Vpp), my DMM was giving me ~92.096KHz for the trigger out of the oscilloscope. I believe, based on the data above, that the DMM is correctly measuring the oscilloscope's trigger out and the oscilloscope's counter, on channel 4, is incorrect. EDIT: See below.

Thanks for your help so far. What do you think?

[ballsystemlord]

I redid the test above using my DMM and channel 4's counter. My DMM claims ~503Khz and the counter counts 164Khz -- without waiting for it to give me a  lower value like last time.
Now neither of these 2 line up with the calculations above, so I'm a bit confused.

I also set the oscilloscope to 100ns/div to redo my original test using the record option and got: 0.0067 (on average minus the outliers), which computes as 1/(0.0067/11) == 1642wfms/s . The counter gave 41.75Khz and sometimes 15Khz and the DMM 19Khz.

So now we have three different ways of measuring, all of which disagree with each other.

[Martin72]

The best way is simply a second oscilloscope.
When I wanted to capture the update rate of my MSO5074, I used a counter at home, but it didn't work properly.
So I took the Rigol with me to work:
https://www.eevblog.com/forum/blog/new-rigol-scope/msg2047141/#msg2047141

Almost 6 years ago again, time flies...

[ballsystemlord]

I decided to do the recording again using the maximum amount of frames which I repeated 10 times for statistical accuracy.
1/(((3.53492443+3.53492619+3.53495844+3.53494414+3.53491179+3.53492468+3.53495636+3.53493569+3.53493560+3.53494433)/10)/458752)

This gives me ~129,776 wfms/s. This is much closer to the counter's value of 164Khz.

[ballsystemlord]

The best way is simply a second oscilloscope.
When I wanted to capture the update rate of my MSO5074, I used a counter at home, but it didn't work properly.
So I took the Rigol with me to work:
https://www.eevblog.com/forum/blog/new-rigol-scope/msg2047141/#msg2047141

Almost 6 years ago again, time flies...

Well, first of all, I was trying to replicate what Dave did with the HD3 which was feeding it it's own trigger signal and then measuring the wfms/s. If it's not possible, I wanted to better understand why not.

Second, as I mentioned above, "Unfortunately, I have only one oscilloscope at this time. Although I could go for one of those really cheap handheld scopes from china, I think I'm better off waiting till I could afford better equipment."

[Sensorcat]

The best way is simply a second oscilloscope.

Yes of course, but he said he does not have a 2nd scope.

I do not think that it is possible to get similar results from different ways to measure this, because the scope is essentially a computer with a non-real-time operating system. There are background tasks, and whenever the OS decides to do some housekeeping, the waveform rate will be temporarily reduced. So the result depends on the interval that is measured. Since the TRIG OUT signal is actually easy to measure (low output impedance, convenient amplitude, moderate frequency), I do not think that any of a counter, a decent DMM, another DSO will miss in counting the signal.

So the rate goes up and down, even when measured with one instrument (verfied with a K2001: max rate results from 490k to 510k WFM/s). You have to decide whether you are interested in the maximum, the minimum, or an average; and which interval should be used to find this value.

Regarding the use of the segmented memory method:

The main difference between my results and the OP are likely the different settings in the number of segments (1,000 vs. 11), which corresponds to a different gate time in the measurement. When the outliers of the OPs results are removed (= housekeeping disregarded) there is a good match. I am surprised, though, about the results that exceed one second, as this means essentially that the instrument is completely stalled during the measurement. I have never observed such behaviour from my instrument. I have an non-hacked MSO5074, upgraded to 200MHz, with firmware 00.01.03.00.03.

[Sensorcat]

I decided to do the recording again using the maximum amount of frames which I repeated 10 times for statistical accuracy.
1/(((3.53492443+3.53492619+3.53495844+3.53494414+3.53491179+3.53492468+3.53495636+3.53493569+3.53493560+3.53494433)/10)/458752)

This gives me ~129,776 wfms/s. This is much closer to the counter's value of 164Khz.

As expected, with a much longer 'gate time', the results are much more stable now, all 3.5349... The extreme outliers from your first measurement remain a mystery.