DAQ 6251: When using a analog window trigger, is there a limit value for a threshold? (lowest possible for bottom window )

[skim150]

Hi all

I am collecting analog voltage signals using DAQ 6251 run by a labview code which is attached with this post.

The voltage signal varies from -10 to 10 V and window trigger is used to collect 400 samples (under 1.25 MS/sec) whenever the signal exceeds a certain threshold (bottom window).

Current condition for window trigger is 9.98V for top and 15mV for bottom.

However, it turned out the acquistion is triggered only when the signal exceeded approximatly 23 mV.

Is the value a limitation for bottom window trigger or just  my DAQ/code malfuctioning?

I would glad if anyone can help with this.

Thank you!

[johnsold]

From the specifcations for the NI 625x devices: Trigger resolution is 10 bits, or  part in 1024. That is equivalent to 19.5 mV on a nominal 20 V range. The accuracy is +/-1% (but it does not say 1% of what). 1% of full scale is 200 mV.  So 23 mV signal seems reasonable as a value where triggering could occur.

You may have a similar issue at the top end of your range when you consider both the accuracy and resolution of the trigger circuit.

Tell us more about your application and perhaps someone can offer suggestions about a more satisfactory approach.

Lynn

[skim150]

Thanks for the information.

To talk about my research, I am recording an acoustic emission while I apply tensile loading to the fiber-reinforced polymer composites.

Whenever the crack is initiated, it emits an acoustic emission and attached sensor collects the signal as a voltage.

I am using an amplifier to increase the voltage signal so that can be detected.

Amplifier have a setting of 40 dB or 60 dB, which can amplify the signal 100 times or 1000 times respectively.

According to previous researches, it has been known that amplitude of acoustic emission varies from 0.1 mV to 0.1 V.

The problems starts from here.

If the amplifier is setted to use 40 dB gain the signal range becomes => 10 mV to 10 V 

If the amplifier is setted to use 60 dB gain the signal range becomes => 100 mV to 100 V 

As DAQ runs under 10V, the amplifier need to set as 40 dB gain but now I knew that I cannot set a trigger window lower than 23 mV......

Is there anyway I can trigger the acquisition with the threshold of 10-15 mV?

How about offsetting the signal about 8 mV so that the total signal can be over 23 mV when an acoustic signal is added?

Please let me know if you guys have any idea about this.

Thank you!

[johnsold]

Perhaps it would be better to use a continuous acquisition and process the data in software. The device has 16-bit resolution which means about 0.3 mV on a 20 V range.

What is your sampling rate? What is the duration of the load test for one composite sample? Are you testing multiple samples simultaneously? What is the expected bandwidth of the acoustic emmision? 

Lynn

[skim150]

Sampling rate is 1.25 MS/sec as the signal's frequency is around 100-500 kHz.

Also the duration of the load test for one composite sample is around 600 seconds and I do not test multiple samples simultaneously.

If you mean time duration when you said bandwidth of the acoustic emmision, each acoustic emssion takes 300 microseconds so I was recording 400 samples per emission (400samples/1.25MS=320microseconds)

Each specimen generates less than 1000 emissions during a loading test and re-arm time of 1ms is commonly used value.

My calculation tells me if I use continuous acquisition, each test generates a file of 24 Gbyte which is really large and I would like to find a way to reduce this.

Can I design a labview code which will filter out each signal which is under a threshold and "writhe to file" only when the signal exceeded the threshold simultaneously with the aquistion?

Or give threshold signal to AI2 channel and use that as a trigger value such as start recording when emission signal (AI1) is over the threshold (AI2)?

Please let me know if you have a idea.

I will wait for yourt reply.

Thank you!

.

[johnsold]

Thank you for the details. 

Obviously it makes no sense to keep all the data. I will have to think about it and probalby try some things to see if the data can be processed fast enough to avoid a buffer overflow. My first impression is that it should be possible but that it will require careful attention to the details.

It will probably be late today or sometime over the weekend before I can get back to this.

Lynn

[skim150]

Thanks a lot Lynn.

I will wait for your reply.

Thank you again.

[johnsold]

Here is a VI which demonstrates the concepts of what I have in mind.

It generates a simulated signal. The signal is sampled at 1.25 MHz and 1250000 samples are generated on each iteration, representing data for one second. The signal consists of a 1 mV 10 Hz sine wave which serves as the baseline and a 400 sample burst of random amplitude 101 kHz sine wave. The burst is inserted into the baseline signal at a random location on each iteration. The manipulation of the amplitude (tanh(rand)/20) is arbitrary and was chosen to generate a significant number of amplitudes below the 10 mV threshold.  Note that the simulation runs faster than actual time. Simulating a 600 second duration test only takes about a minute on my computer.

The Trigger and Extract Segment.vi processes one second of data at a time. It locates the index in the array of data where the amplitude first exceeds the threshold. It subtracts 10 (arbitrary) from the index to provide some pretrigger samples. Then it extracts a segment which includes the pretrigger samples, 400 burst samples plus 10 more to get past the actual burst in the simulation. The Triggered? output is true if the index is within the data array.  It does not handle the case where the burst occurs within less than 400 samples of the end of the array.

Conditional indexing is used in the main loop of the top level VI (Window trigger substitute.vi) to only pass to the output the segments which included valid triggers.

From some testing using the Profiler it appears that the Trigger and Extract Segment.vi takes 6-7 ms to process 1 second of data. Based on that it should be quite reasonable to do this processing in parallel with the data acquisition. You could use TDMS to save the data to file as it is detected or simply accumulate the data and write it to file after the program ends.  The memory required for the  triggered segments is a few MB, depending on the number of segments found while one second of data occupies ~ 20 MB. Keeping the data in memory for the duration of the test will not be limited by memory.

I saved the VI back to version 2010. I got one warning so if something does not work, let me know what version you are using and what errors are reported.

Lynn

Edit: changed VIs to defaults with minimal data in indicators to reduce size.

[skim150]

Lynn

Thank you so much for your detailed help.

I will try with your code during the weekend and update youthe result..

Thanks again.

[johnsold]

Note that the version I posted does not deal with the possibility that an emission burst will occur such that it overlaps the end of one acquisition block and the beginning of the next one.

One way to handle that situation (which will happen sooner or later in your real experiment) is to pass all the data after an emission to the next iteration via a shift register. Before starting the trigger detection process in any iteration first append the new data to the leftover data from the previous iteration. You may also need to put a modified Trigger and Extract Segment.vi into a loop to find all the emissions in one block of data.

Lynn