DFD Processing State Initialization

[maxwellb]

Hi,

I'm having a problem initializing Digital Filter Design processing VIs.

Below is an example of the issue. I'm processing a 500 kS data set in 5 100 kS blocks. The top graph is the input to the filter. The bottom graph is the output.

I see an artifact like this at the start of every data set. I am using the "DFD NStage MRate Filtering with State" VI to process the data. On the first block of data, I initialize the filter state to an empty array. Below is the VI that I pass each block of data to. init? is TRUE for the first block and FALSE for all others.

I'm hoping that there is some way to initialize the filter correctly and avoid this artifact, but I don't know what it is. Anyone have any insight?

Thanks!

[TaylorG]

Hi maxwellb,

Rather than using a button to control whether or not the filter is initializing manually, try using the First Call? function.  This is a boolean that returns TRUE the first time the VI runs after the first top-level caller starts running.  That way your filter is not initializing more than once.  I've attached a link to the LabVIEW help document for the First Call? function.  Let me know if this works!

First Call? Function

Taylor G.

National Instruments

Applications Engineer

www.ni.com/support

[maxwellb]

Taylor,

Thanks! I was not aware of that method.

However, I've tested the initialization button (really an input to a subVI), and the program is definitely not being initialized more than once. It must be something else.

[TaylorG]

Maxwellb,

After further investigation, it looks like you've set up somewhat of a toggle situation between the "True" and "False" case of your initialization case structure.  Having a TRUE constant in your "False" case would simply toggle back to the "True" case after the iteration, and having a FALSE constant in your "True" case will toggle back to the "False" case after its iteration, resulting in the toggling back and forth between the two cases.  Also, that TRUE constant is wired to the Stop if True conditional terminal, which would kill the loop.  Perhaps try changing the TRUE constant in the "False" case to a FALSE constant.  This would leave open the Stop if True conditional terminal, however.  At what point do you want the loop to stop?   

[maxwellb]

Taylor,

Sorry, my block diagram is unclear in this picture because it only shows the TRUE case. The FALSE case has a TRUE constant wired out to the stop terminal.

I did this as one attempt to remedy the artifact. When init? is TRUE, which only happens on the first block of data, the while loop runs twice. The filter state is initialized, the first block of raw data is filtered, then that same block of raw data is filtered again without the filter state being re-initialized. This seems to help my problem somewhat.

My program looks somewhat different now. Here is the updated version, showing the FALSE case. And as you can see, I am now using the First Call function. : )

[TaylorG]

Maxwellb,

Sorry if my last post was a little hard to follow.  I'm still concerned about that TRUE constant that you have in your "False" case.  It looks to me that every time you enter the "False" case, you are stopping your loop with that constant.  How many iterations of the while loop are you wanting to run?  Glad to see the First Call? function in there as well!

[maxwellb]

Taylor,

The VI I've shown so far is designed to execute its loop only once each time it is called, except for the first time it is called, in which case it runs twice. It does store the states of the filters in the while loop's shift registers for later calls.

The below snippet shows the whole calling VI.

I am configuring a PXI-5112 100 MS/s digitizer, then fetching several continuous 100 kS chunks of data in the first for loop.

These chunks are post-processed in the second for loop. First, the 8-bit data is converted to double precision waveforms ( 8 BIT 2 WVFM VI). There are two channels, so I label the waveforms Ch 1 and Ch 2 and store them in a cluster. I then mix the data with an equivalent frequency sine and cosine to decompose the data into In-Phase and Quadrature signals and shift the amplitude and phase information to DC (MIX IQ VI). Then, I filter these signals with a multistage, multirate filter resulting in a decimation factor of 500 (FILT I&Q VI).

The FILT I&Q VI is the VI that I have been showing thus far. Here it is again for ease of access.

I call this VI once for each block of data and the while loop executes once, but as I mentioned earlier, the state of the filter from earlier calls is stored in the shift registers.

[Samuel_S]

I agree with Taylor it appears that you have a situation that is toggling between the true and false case inside the while loop which may be killing your loop early. I believe you are trying to create logic that is an either or situation. I would recommend looking into an event structure and creating a way to ensure that the loop is only running a determined amount of time.

Are you still getting the initializing issues? Have they changed? 

[maxwellb]

Sam,

I am still getting the initialization issues. They have not changed.

I kill the loop on purpose. This VI is an "Action Engine" type VI. It is designed to execute the loop only once per call. The only reason I use a loop in it is to store the previous state of the VI in the shift registers.

[TaylorG]

Could you possibly need some execution timing?  You could add a Wait Until Next ms Multiple with say, 100 ms of time to free up your processor within your While Loop.