Data Acquisition (DAQ) and Control from Microstar Laboratories

Software Triggering

data acquisition filtering data acquisition software channel architecture enclosures services

Home | DAQ Techniques | Download as a PDF | View as one page

<< Previous 1 2 3 4 5 6 Next >>

Software Triggering, Part 3

Once software trigger events are detected they are... in software. This gives the flexibility to do some things easily that would otherwise be enormously difficult, perhaps impossible. This part shows how applications can use software triggers to process data in blocks rather than individual samples.

Or go back to start at page 1 of Software Triggering.

Selecting Data in Blocks

data acquisition hardware board
Software triggering can be applied to data streams captured at absolute maximum rates.

Suppose for example that data are captured at 1 million samples per second. 2048 samples are selected for processing by an FFT command every 0.1 second, producing 1024 magnitude output terms per input block of 100000 terms. Most of the time, nothing happens and the FFT data can be discarded. To this point, no triggering is needed. Just use a SKIP command to retain the first 2048 samples from each block of 100000 input samples, route this data for processing by the FFT, and discard the rest.

Most of the time, nothing happens. However, if an event occurs any time within the 0.1 second interval spanned by a block of 100000 samples, three FFTs are computed. One FFT is applied to the first 2048 samples from the current block. The other FFTs are applied to the first 2048 samples from the preceding block, and to the first 2048 samples from the block to follow. How can you do this?

Thinking about this in terms of blocks, it is relatively easy. For example, if the event occurs in the input block 5 (input samples 500000 through 599999), you want to keep the FFT results for blocks 4, 5, and 6. You can determine the input block number easily from the event location.

 (event location) / 100000 

One FFT every 1/10 second is easy for a DAP board to do. So instead of worrying about when to perform the FFT operations, it is easier just to stream each 2048 point data block into FFT processing as it arrives. The resulting blocks of 1024 FFT output values stream out. If an event occurs, you keep the resulting FFT blocks, otherwise they are discarded. The locations of desired FFT results in the FFT output stream are calculated easily.

 (block number) * 1024 
Event adjustments with TRIGSCALE

Processing Implementation

All of this theory is fine, but event locations are not the same as ordinary data. How can you apply these calculations to events? Easily, as it turns out. The DAPL system provides a command called TRIGSCALE that takes a trigger input derived from analyzing data at one rate, and produces from it a new trigger event that operates at a different data rate. Use the modified event locations when selecting data from the FFT output stream.

Here are the configuration lines that you would use.

  Trigscale( RAWtrig, 0, 1024, 100000, FFTtrig )
  Wait( FFTresults, FFTtrig, 1024, 2048, FFTselected )

The details:

  1. Analyzing the original sample stream produces events in trigger RAWtrig, as described in Part 2 of this article.
  2. The Trigscale command takes an event location from trigger RAWtrig, without any offset adjustment, and divides by 100000. It truncates the fraction to produce the input block number.
  3. The Trigscale command then takes that intermediate result and multiplies it by 1024 to obtain the location of the associated FFT output data block, placing this new event location into trigger FFTtrig.
  4. The Wait command selects data from the FFT output stream in the usual manner, using the locations from the FFTtrig trigger, and placing the data into transfer pipe FFTselected.


In this example, the application captures data when it observes something interesting. However, it is not completely rigorous about capturing all data where anything interesting occurs. If the last block analyzed for an earlier event happens to contain a new event, it will be impossible to respond to this event properly. The data for the "block prior" was taken by previous processing. The DAPL system cannot partially respond, which means that the FFT block following the secondary event will be missed.

You can be sure that all events are covered if you use the DEFERRED operating mode and HOLDOFF properties (link opens 1.27MB PDF manual) when you declare trigger FFTtrig command in your processing configuration.

This part has shown triggered processing of complete data blocks from a single data channel. In part 4, we will look at an application that processes multiple channels.

<< Previous 1 2 3 4 5 6 Next >> View as one page

dap 5400a