LabVIEW
Single tone extraction and Multi tone extraction
Dimitrios,
Ugh! It is condsidered good practice to keep the block diagram to a size which will fit on one screen. Yours is 5-6 screens wide. This makes it very difficult to see what is going on.
Other comments:
- Avoid the use of sequence structures. They are almost never needed in LabVIEW.
- Avoid the use of local variables. They require extra copies of the data, can lead to race conditions, are slower than wires, and make it difficult to tell where data is used or originates. Use wires.
- You have a mixture of Extended Precision, Double Precision, and Integer data types. The mathematics is all done in Double precision in your code so why not just use that data type. [Note: At first I thought this might have been part of the problem with your code due to round off, but I think I found something else.]
- Duplication of code: When code occurs more than once It should usually be converted to a subVI. Also, duplicating constants (like the 16000 wired to for loop N terminals) can become a problem if you ever need to change the value: Did you find and change all of them?
- Rube Goldberg code: The for loop with the unitialized shift register (probably should be initialized) and the divide afterwards can be replaced by Array Subset and Mean.vi. This much more clearly indicates what to code does and takes up much less block diagram space.
Now, on to the problem with the cavity. The Extract Tone Information VIs use the FFT internally. They process the spectral peaks to find the tones. Read the Detailed Help for more information. When a signal processing VI does not produce the results I expect, one of the first things I do is to look at the input data on a graph. The spectrum of the signal you are feeding to Extract Tones is shown below. Both graphs have the same data. The left graph has an expanded X-axis near zero.
Note that there is only one true peak, at about 7E-13. The high point at zero may represent a low-frequency peak or the residual DC component after removing the mean. if it does represent two components they are mixed together in a way the cannot be separated with the data you have. The zero point is about 27 dB below the true peak. That may be near or below the default threshold for tone detection. The fact that it returns two "peaks" indicates that it found something.
I suspect that the problem is in the data you are generating. I did not try to figure out what you are doing there.
One othe comment: It might be better to normalize the data in some way so that you are not repeatedly multiplying and dividing by 1E14 sized values. Do all the calculations with values within a few orders of magnitude and then scale the result for display at the end. Using really large and really small numbers in the same calculation can cause subtle problems - subtle in the sense that they are not the obvious cause but often not subtle in the magnitude of the errors.
Lynn
