Trigger position in SDK

[MikeWatson]

Hello. I'm trying to analyze an analog signal using the WaveForm SDK on Linux (Ubuntu 18.04). But I'm having troubles controlling the trigger position in the buffer of 8192 samples. I want the event of interest located on the right end, so that the buffer captures what happened *BEFORE* it, instead of after it (to avoid repeated patterns.)

I'm looking for a narrow spike >5V to trigger. There is only one such data point in the buffer of samples, and I can verify that. My code looks like this but the trigger position is not fixed in each run. Some times the >5V point is very early in the buffer.

Thank you!

    // Modified from sample code: analogin_acquisition.cpp

    // sample rate
    // 50,000 Hz, 8192 samples, 
    // 163.84 ms range
    // 0.00002s or 20 us between samples
    FDwfAnalogInFrequencySet(hdwf, 50000.0);
        
    // configure trigger
    FDwfAnalogInTriggerSourceSet(hdwf, trigsrcDetectorAnalogIn);
    FDwfAnalogInTriggerTypeSet(hdwf, trigtypeEdge);
    FDwfAnalogInTriggerConditionSet(hdwf, trigcondRisingPositive);


    FDwfAnalogInTriggerLevelSet(hdwf, 5.0);
    FDwfAnalogInTriggerHysteresisSet(hdwf, 0.05);
    FDwfAnalogInTriggerHoldOffSet(hdwf, 0.15);	// cycle is 0.16

    // set trigger position to the right
    // time range is (-82 ms, 82 ms)
    FDwfAnalogInTriggerPositionSet(hdwf, 0.08);	// <-------- look here


    FDwfAnalogInConfigure(hdwf, 0, true);

Digilent.adept.runtime_2.21.3-amd64.deb

Digilent.waveforms_3.16.3_amd64.deb

The WaveForm application works properly with the same parameters.

 

Edited September 21, 2021 by MikeWatson
added screenshot

[attila]

Hi @MikeWatson

The difference I notice is that in the WF app the sampling rate is 80kHz and in you app 50kHz.
The 5V glitch may be filtered out by the lower rate average sampling.

Also notice the noise band. This is a simultaneous lower rate capture of min/max samples.
It indicates that you have higher frequency components between 4.6-5.2V and glitches down to ~2.5V and up to ?7V.
Depending in the sampling rate, the 5V trigger may capture at these higher frequency components.

1. Use the same sampling rate.

2. Try using the decimate filter for the trigger detector. This will look at the raw 100MHz samples rather than the default averaged samples at specified sampling rate.
FDwfAnalogInTriggerFilterSet(hdwf, filterDecimate)
Set the trigger level to at least 5.5V

[MikeWatson]

On 9/21/2021 at 10:28 PM, attila said:

Hi @MikeWatson

The difference I notice is that in the WF app the sampling rate is 80kHz and in you app 50kHz.
The 5V glitch may be filtered out by the lower rate average sampling.

Also notice the noise band. This is a simultaneous lower rate capture of min/max samples.
It indicates that you have higher frequency components between 4.6-5.2V and glitches down to ~2.5V and up to ?7V.
Depending in the sampling rate, the 5V trigger may capture at these higher frequency components.

1. Use the same sampling rate.

2. Try using the decimate filter for the trigger detector. This will look at the raw 100MHz samples rather than the default averaged samples at specified sampling rate.
FDwfAnalogInTriggerFilterSet(hdwf, filterDecimate)
Set the trigger level to at least 5.5V

Thank you @attila. I set the sample mode to Min/Max in the app and saw the glitch goes up to 7V. So I did what you suggested and set trigger level to 7. Now I have consistent triggers. One thing I didn't do right is the trigger position. The number means where in time to center. So a negative number moves the trigger position to the right. Should this be in the API docs? Thanks again!

    FDwfAnalogInTriggerFilterSet(hdwf, filterDecimate);

    FDwfAnalogInTriggerLevelSet(hdwf, 7);
    FDwfAnalogInTriggerConditionSet(hdwf, trigcondRisingPositive);

    FDwfAnalogInTriggerPositionSet(hdwf, -0.05);