5681 timing in "Scope mode"

[JÞB]

I'm running into some unusual problems understanding the sample timing of the 5681 in scope mode.

the Help is of little help. so, a few quick questions assuming an internally triggered capture of 300mS RF Burst with a gate at 50 to 250mS is desired using the default 200 samples is desired.

I have set my capture time to 300mS I appear to trigger on the correct edge. 

Why do I apparently get more than 300mS in my capture?  What is the sample rate of the 5681? what effect does changing samples per capture or capture duration have on sample timing?

[PeterGC]

Hi Jeff

The capture time is not the same as measurement time.    There is averaging and triggering done that helps determine your measurement time.   If you look in the manual for the 5681

http://www.ni.com/pdf/manuals/375541a.pdf

Page 4 contains a formula which outlines expected measurement time based on capture time and data points.   Keep in mind performance may vary based on triggering and averaging settings.

Regards,

[JÞB]

Peter,

With all due respect I did not ask about measurement time.  Frankly, I do not care about that (Besides, If I did care I could read all about it.)

I did ask about sample timing and what effects there are on capture time and sample timing while varying number of samples and capture time.

I'll post some screenshots tomarrow.  And probably lambaste the SFP and Driver again (What IS that "Apply" button doing there!, Why are there seperate Reads for each Mode?)

Have you seen this?  Probably not But this 5681 SFP and driver are making a great case study.

[JohnFenner]

The device's sampling rate is constant at approximately 142 kHz.  The samples collected during the capture time are divided and averaged into the number of data points you select.  In your example, 142 kHz * 300 ms gives us 42,600 samples.  42,600 samples / 200 data points results in 213 samples averaged per data point.  Regarding the gate, the first 7,100 samples and the last 7,100 samples are excluded from the average gate power.  In my screenshots, you can see I'm generating a pulse of RF every 50ms, and the 568x Soft Front Panel is capturing 6 periods (300ms) off a positive edge trigger.  What leads you to believe the 200 data points you are collecting are not in fact captured during the 300 ms following the trigger?

[JÞB]

I guess its just a triggering problem.  After further research.

Yes, those a 297mSec bursts every 3.5 seconds as expected.

Now going to scope mode (And hitting that "Apply Settings" button that should not be there)

Well thats a nice capture! Let's try again.....

Whoops  That's what is hosing up my gated measurements!

And I thought "Rising edge" meant something more in keeping with what a user would expect from similar instruments with triggers.  

[JohnFenner]

Hi Jeff,

In scope mode, the power meter returns averages to the user, but it triggers on raw sensor data.  This can cause some unexpected results.  For instance, you can have a situation where you have a waveform that appears to be entirely above the triggering threshold, but a single sample fell below that threshold.  The next sample rises back above the threshhold resulting in a positive edge trigger in the middle of your burst.  I suspect this is what's happening to you.  The solution is to increase the noise immunity.  Noise immunity is the number of internal samples (not returned data points) required to trigger the capture.  As immunity increases so does trigger latency, so use the negative trigger delay to correct for that (-1 * Noise Immunity * .007 mSec).

[JÞB]

We will give it a shot!  thanks for the feedback.  Thats good information to consider adding to the help file!

Hold ON.  I Did have a negative trigger of 5mS  

are you saying I also need a noise immunity of -715 or is Noise immunity of 715 equal to (and redundant of) a trigger delay of -5mS?

Or is it correct that a noise immunity of 715 would provide an arming gate for the trigger of 5mSec requiring a -5 ms Delay to capture the rising edge?

[JohnFenner · Accepted solution]

Noise immunity for the internal trigger is anywhere from 1 to 10 samples. One is no noise immunity. The first sample that rises above or below the threshhold will trigger. If we set it to 2, we have to get two samples above or below the threshhold to trigger. If one sample rises/falls but the next one doesn't, we don't trigger and we start over waiting for the trigger. Given that we now need two samples to trigger, we start collecting data about 14 microseconds later. If we want to get those samples back, we set the trigger delay to -.014ms. The same logic applies for higher amounts of noise immunity.