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 4

This page considers how you can use software triggering as an event detector to control acquisition on many data channels. This is perhaps the most common application of software triggering.

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

Multiple Channel Acquisition with Triggering

The application is a vehicle crash test. You will observe data for stress, buckling, and fractures at 100 sensor locations on an instrumented vehicle – and in a fraction of a second it is all over.

You have just one chance to capture the measurements. There is too much data to collect it all continuously, but you cannot afford to miss any relevant data or risk drowning your system with irrelevant data before the crash event has occurred.

crash test configuration

Suppose that you are using a DAP 5400a/627, sampling 8 channels simultaneously, with each of the 100 channels sampled at each 100 microsecond interval. During an experiment covering 0.5 seconds, you will collect about 4 million samples. The host interface can transfer about 2.5 million samples under ideal circumstances. Depending on what your application processing does with the data, you might be able to move perhaps 1 million samples into your application software during the event. The other 3 million samples are captured and buffered on the DAP, and sent when the host software is able to accept them.

Reliable Triggering

signal interface, channel expansion board
Software triggering is fully compatible with multiple-channel and multiple board applications.

A high-speed transient glitch propagating along a sensor wire could easily set off an electronic triggering circuit. A glitch of that kind would not be persistent. The real signals of a crash event would be very different. When using software triggering, you can combine processing with triggering, so that real events are distinguished from the meaningless noise glitches.

Suppose you select one of the microphone channels that will respond to early contact, and connect it to signal channel IPipe0. You don't want DC offsets on this channel to make the triggering too sensitive or too insensitive. You can use a running average over a long time window to approximate the offset level for cancelling it.

On the other hand, you don't want a single "spike" to prematurely trigger. You can use a running average with a short time window to smooth out noise spikes. To trigger, the signal must reach the triggering level and stay there for a few samples.

The following configuration cancels DC offsets, smoothes out spikes, and triggers when the signal level deviates from the baseline level consistently through a window of 7 samples.

   pipes  pDCoff word, pCleaned word
   pipes  pDiff 
   trigger   tCrashEvent
   ...
   pdefine  CrashCapture
     raverage(IPipe0, 400, pDCoff)
     raverage(IPipe0, 7, pCleaned)
     pDiff = pCleaned - pDCoff
     ...

Now you can trigger reliably on the processed pDiff signal, as described in other parts of this article.

 
     Limit( pDiff, OUTSIDE, -20000, 20000, tCrashEvent )
     ...

Accounting for Many Channels

The crash is detected on just one channel, but data are collected in many channels. As we saw in Part 3, the position of the data in a triggering channel must be used to determine the associated position of the data in channels where data are taken.

The Wait command makes this very easy. When you capture data from multiple channels of an input channel pipe, the DAPL system will automatically account for the number of samples in the individual triggering channel and in the multiplexed channel pipe. You can select extra samples from just before the crash to establish a statistical baseline, and then capture the 4 million samples for the crash event. The complete set of samples is sent straight to the host system.

    ...
    Wait(IP(0..99), tCrashEvent, 12000, 4000000, $Binout)
  end
Multi-channel triggered collection

All examples so far have shown the measurement process terminating after recording a known, fixed number of samples. The next part will show an example where intelligent triggering is also used to terminate the sampling when the number of samples cannot be known in advance.

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

counter/timer cards