LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Continuous multi-channel decimation

Hi,

 

I have built up a VI to perform decimation (with optional averaging) on a waveform using 'Decimate (continuous).vi' from the Signal Operation Pallete and I have managed to get it to work such that it preserves correct values for dt and t0. The incomming waveform will possibly have a number of samples that is not an exact multiple of the decimation factor, hence the need for continuous decimation.

 

decimate waveform.png

 

I would like to know if there is an elegant way to do this for a multi-channel waveform, where the number of channels is not known at compile time?

 

Cheers,

Pat.

0 Kudos
Message 1 of 5
(3,111 Views)

Hi Pat

 

Is the number of channels known before this code is executed? If so, you could use a For loop to efficiently build an array out of the waveform constants and then use your code inside another For loop to index the elements for processing.

 

A While loop could be used but you will have to be careful how you build your array. I would recommend staying away from this if you can.

 

The other option is to use a Producer/Consumer Framework for Data. There is a template that is shipped with LabVIEW and you can find it in the popup window that appears when you click File>>New.. Use the top loop to work on acquiring your waveform and queuing the data and the bottom loop to process your information.

Noah | Applications Engineer | National Instruments
0 Kudos
Message 2 of 5
(3,062 Views)

Hi Noah,

 

I think the issue with putting this code inside a loop (of any kind) is that the 'Decimate (continuous).vi' stores it's state internally and buffers some samples if the number of incomming samples is not an exact multiple of the decimation factor, it then uses these samples the next time it is called. This would result in samples being mixed between the different channels of my waveform array.

 

Cheers,

Pat.

0 Kudos
Message 3 of 5
(3,048 Views)

That would be true with the continuous version. Is there a reason why the Decimate (single shot)Vi will not work? This would allow you to use a For loop and decimate each waveform without mixing waveforms.

 

If the waveforms are built into an array and then passed into a For loop with indexing enabled you could reset the Decimate (continuous)Vi every time there is an iteration of the For loop using a VI from the compare palette. This would give you the same functionality of the Decimate(single shot). Is there a specific reason why you want to use the Decimate (continuous)Vi?

Noah | Applications Engineer | National Instruments
0 Kudos
Message 4 of 5
(3,021 Views)

Hi Noah,

 

My reason for using the continuous VI is that the incomming waveform will not necessarily have a length that is an exact multiple of the decimation factor. Therefore I want the decimation (and averaging) function to buffer the leftover samples from each call to use when more samples arrive (my understanding from testing with a single waveform is that this is what the continuous VI does).

 

I found the following KB document that sort-of describes what I am trying to do and a potential solution (http://digital.ni.com/public.nsf/allkb/0388185F78143B82862578D9004CFA25), but to me the solution looks kludgy and it also relies on knowing the number of channels at compile time.

 

I decided to have a go at re-implementing the buffering functionality of the continuous decimation VI for a multi-channel waveform using the single-shot decimation VI. I'm not sure how efficient it is performance wise but it appears to do the trick:

decimate waveform multichannel.png

 

This does rely on all waveforms in the array having the same length, t0 and dt, but as my waveform array is coming from a DAQmx acquisition task this is not a problem.

 

Regards,

Pat.

0 Kudos
Message 5 of 5
(3,011 Views)