Why is the outcome of the envelope detection vi different when run within a for loop

[mmiers]

Given that signal 1 and signal 2 are identical what could cause  the outputs at appended array and appended array 2 to be different. The output at appended array 2 comes out incorrectly. Given only one band specification the subvi works in the loop. With more than 1 band specification the output from the loop is not correct.

[billko]

Could you define "incorrectly"?

[JÞB]

From where I seen simmilar issues: (And these get to be head scratchers)

Appended Array 1 is the output of two seperate dataspaces (prealocated clones)

Appended array 2 is two output from the same dataspace called twice.

I bet dollars to doughtnuts there is an IIR filter in that vi that assumes (correctly, because we know nothing about the signal) a zero magnitude initial value (which is almost never the actual case) and has a reset implied. this introduces an initial transient in the filtered signal that is different in the two loop iterations since the filter has been "Pre-settled" in the second iteration.

[I has a nightmare of a time finding that when using the Mod Toolkit to generate bursts of pi/4-QPSK until I took I/Q to polar and saw the transient on Rho  - the work around was to just generate the burst twice once, to settle the filter and once to get a useful signal throwing out the first burst]

[billko]

---

@JÞB wrote:

From where I seen simmilar issues: (And these get to be head scratchers)

Appended Array 1 is the output of two seperate dataspaces (prealocated clones)

Appended array 2 is two output from the same dataspace called twice.

I bet dollars to doughtnuts there is an IIR filter in that vi that assumes (correctly, because we know nothing about the signal) a zero magnitude initial value (which is almost never the actual case) and has a reset implied. this introduces an initial transient in the filtered signal that is different in the two loop iterations since the filter has been "Pre-settled" in the second iteration.

[I has a nightmare of a time finding that when using the Mod Toolkit to generate bursts of pi/4-QPSK until I took I/Q to polar and saw the transient on Rho  - the work around was to just generate the burst twice once, to settle the filter and once to get a useful signal throwing out the first burst]

---

Wow, that hurt my brain.  But I do understand what you were talking about.

[JÞB]

@Minion

Hurt your brain.... you should have seen the run on Tylenol at the local mini mart!  A few million invested in brand new VSTs and the test system cannot generate a RF burst?  Well, it could and does!  I understand my client had the first VST qualified on a production floor ... And numbers 2-8! VIE and I debate who got out the next dozen but, some of them were my client's.

Brain-hurt is a good experience but, keep duct tape on hand and wrap your head as needed.

[mmiers]

The output from within the loop is the same as the non-loop output except that the first 27 members of the output arrays are missing. So if the no-loop output signal array contains members 0 to 499 the loop output will contain members 0 to 472  and 472 matches 499, 471 matches 498 etc. This occurs any time the loop performs more thatn one iteration. If the input is organized so that the loop only perfroms one iteration the outcomes are identical.

[mmiers]

I think that you are on to something with the reset idea. I've had problems before when the data check routines on vi's decide that data is not continuous because a t0 somehow gets assigned at a processing time instead of at acquisition time. I don't really understand the two vs one data space or how to fix the problem.  I want to process in a loop so that I can change the filter spec dynamically and have a filter sweep a data set and deliver output to an intensity map.