Finite acquisition at different sampling rate

[uil89]

Hello guys,

I'm would like to acquire (cDAQ9189 & NI9205) an analog signal at differente sampling rate: 1 sec at 1000 Hz and then 5 min at 100 Hz. Data acquisition should start with an external trigger with 1 sec of pretrigger. The .gvi is done like this:

create task --> create channel -> timing (1000 Hz) -> reference trigger (1 sec, external source) -> start task -> read data -> stop task -> timing (100 Hz) -> start -> read data -> stop task

I have this problem: after the trigger is given, the first acquisition starts correctly but when the task stop for the first time the new task waits for another external signal to start.

Is there any way to start the second acquisition automatically ?

Could this work : https://forums.ni.com/t5/Example-Programs/Start-a-Task-with-a-Specified-Delay-After-a-Trigger-Using/...   ??

thanks

Guglielmo 

[Kevin_Price]

The first 2 options that occur to me:

1. Right now you stop the task, reconfigure timing, then start it again.  This leaves your prior trigger config intact and explains why the task waits for the ref trigger signal.   You could instead both stop and *clear* the task, then fully reconstruct it for the lower rate without including any triggering the second time.

2. You could let the original task continue running at 1000 Hz, but simply decimate by a factor of 10 in software, i.e., only keep 1 out of every 10 samples.  Sure it feels wasteful, but it's really dang easy to implement and you get a *continuous* data stream this way.  (The earlier method that does reconfiguration will make you miss things for a brief time).

3. Oops, just thought of a 3rd.  You could actually configure 2 distinct tasks.  They just can't both run at the same time.  But as soon as you stop task 1 you can start task 2.  If you need to repeat, then as soon as you stop task 2 you can restart task 1.  And so on...

-Kevin P

[uil89]

Hi Kevin

how do you propose to do the 3rd?

thanks

[johntrich1971]

I would do the second. The other approaches are going to result in lost data.

[Kevin_Price · Accepted solution]

---

@johntrich1971 wrote:

I would do the second. The other approaches are going to result in lost data.

---

First, I agree.  I'd usually prefer approach #2 as well.

Nonetheless, below is a minimalist example of what I meant in #3.  Tested successfully on a desktop X-series board.  (The not-so-commonly-used little function in the loop is "Rotate Right with Carry".  I only use it to alternate F/T for even/odd numbers, and therefore alternate which of the 2 tasks is selected to start, run to completion, and stop on that particular loop iteration.)

-Kevin P

[Kevin_Price]

---

[deleted inadvertent double-posting]