The df of power spectrum differs between start program and after a change

[homerus]

Hello everybody,

In the program i made to calcultate the power spectrum of a signal, and to present this in a graph, i encounterd some behaviour i cannot explain.

So i was hoping that someone here can help me.

The behaviour is this:

When i start the program -> and select "Kanaal 1 aan"  the calculation is started ik can see data going in and out.

For testing i setup a 200 Hz test signal.

However the graph i "default" set it up : from 100 to a 1000 Hz stays empty.

When i choose X scale to AUTO it shows me a scale from 0 to 0,5 Hz. and a peak at 0,2 Hz

Which is weird because my test signal is 200 Hz

I also created a option to see the complete spectrum, 1 to 22000 Hz

When i press that button, is see the graph appeare, and when i switch back to the default (100 to 1000) the graph also is correct(with the peak at 200 Hz)

After a day or two puzzling is saw that the "df" of the powerspectrum Vi is 0,01 and after the button pressing is 10(so 1000 times bigger)

Which explains the different position of the peek (0,2 -> 200)

The question is how could this be explained, and how can i solve this?

[crossrulz]

Duplicate post

[homerus]

Yes sorry about the double post. Something went wrong with the internet connection.

The first one can be removed(i searched the forum but could not find how to do this :S)

However i think i solved it, the question is of i am right?

It seems at startup of the program the df is setup to a default value from the Spectrum Measusrement Vi.

And because the signal gets filtered through the bandpassfilter, the waveform becomes a 1D array, and there is no (frequency/#samples)component in the signal so there could not be a "df" to be calculated.

I now fixed it by putting a "getting wmf components" at the source of the signal, and put the df compontent to a "build waveform" with the 1D array from the bandpass filter. to the Spectrum Measusrement Vi.

And now when i start the program its fills my graph, with a spike at 200 Hz.

I attached a picture of the fix i made.

Can somebody support this theory?

greetings

[johnsold]

That seems to be a likely cause of the issues you saw.

I would suggest setting the sampling rate and number of samples to generate on the simulation to be the same as you will be using with the DAQ devices. By doing that you will get the same amount of data and the same dt and df results as when you measure real data. This will show better whether you have the graphs and files set the way you want.

General comments:

- The only way to stop your while loops is on an error from feedback node outside the loops. This implies that you are using Run Continuously to operate your program.  This is NOT good practice for many reasons. That option is primarily for testing small segments of code which will not be inside a loop. Your program should be constructed so that everything which needs to repeat is inside a loop. Use a for loop if the number if iterations is known before the loop starts. Use a while loop if the stop conditions will be determined while the program is running. While loops should always have a stop button or other means for the user to stop them. It is also not good practice to repeatedly close and re-configure the DAQ setups, which Run Continuously forces to happen.

- The use of local variables is discouraged. They are not really local variables in the sense that term is used in text-based programming languages. They are better described as remote access points to a front panel control or indicator terminal. Use of wires is better. It avoids the possibility of race conditions, avoids extra copies of the data, and is much faster. Wires can easily be used evrywhere you have locals.

- The case structures at the left containing many Visible poperty nodes are unnecessary. Just wire the Geavanceerd kanaal termials directly to the property nodes.

- It appears that you have two almost identical copies of the code. This is a situation which cries out for subVIs. By using subVIs you only need to change things in one place if the requirements change or a bug is found. It also makes the block diagram much smaller and the code more readable.

Lynn