Why do FFT frequencies change when changing the #of samples (at same rate)? / Integration start values

[Eisbein]

Dear All,

maybe I am mistaking somewhere, but there are two things I just don't understand. Maybe you can get me back on track, because I couldn't find any hints in the Forum.

I use an accelerometer and integrate acceleration to velocity I then feed to a FFT display. 

1. I use a constant smapling rate, but can adjust the number of samples ("Measurement Time" x "Rate"). When I change the measurement time (number of samples) the frequencies I get from the FFT, like fundamental or harmonics, change at the same time. Going from 1s to 0.5s approx. halfs the fundamental frequency. This is odd because dt should stay the same because of the constant rate.

Am I overseeing something here?

2. Also, the amplitude of the fundamental frequency bounces from 0 to a value and back which I assume is because of the start condition of the integration. As I am looking for sinus wave forms and the accelerometer gives "0V" at no acceleration I am assuming that the default start condition of "0" was about right. Fiddling with the bandpass setting doesn't help. As I couldn't find anything in the forum, can anybody give me a hint how to set the start condition of the integration (or if this is because of anything else what this could be). I tried a feedback from the last value of the previous iteration, but then I just get a flat line (0).

The follwing reading (blue line) is already averaged over 15 values, but in fact the unfiltered reading goes from 0 to a value and back aso. The red line is what I get from another sensor I just use witout the integration.

[rpursley8 · Accepted solution]

The sampling rate in the time domain directly controls the 'bandwidth' of the FFT.

The length of time you are sampling directly controls the 'step size' of the FFT.

Sample for 1s of time and each FFT point represent a 1Hz step in frequency.

0.5s -> 2Hz step

[dsb@NI]

Test your integration algorithm with a well behaved (simulated) test signal. How does it respond when you input DC, a ramp, 1 Hz sine wave? Once you have verified that your signal processing handles all the expected use cases, you can use the same signal processing confidently on acquired data.

To set the initial condition, you might need to define what successful integration looks like for your expected signal (i.e. for a continuous sinewave with zero DC offset, the integrated result should also be a continuous sinewave shifted by 90 deg, scaled by 1/(2pi*f), with zero DC offset). Then, set the initial condition to achieve the best integrated result according to your success criteria.

[altenbach]

I am not going to stare at a blurry truncated picture. If you want specific help, attach a simplified version of your VI. Make sure all controls have reasonable default data, then explain how you run it, what you see, and what you expect to see instead. Thanks!

[Eisbein]

Hello Randall,

that explains it perfectly.

Odd, but scaling X with samples/rate did it.

Thanks a lot.

Ralf

[Eisbein]

Hello Doug,

good idea to use a test signal, and I did. It looks smooth and as it should be. See pictures attached.

Using the signals from the DAQ box (6216) and the accelerometer the integrated signals jump all over the place.

We recently replaced our RION accelerometer that gives velocity (mm/s) by a Kistler that gives V/g. With the RION everything worked perfectly. So I am assuming it has something to do with the integration. I tried to feed back the last X-Values as start values for the new integration.

Didn't make it better.

The accelerometer has a limit frequency of 26 kHz, so this should be good enough. I checked with NImax, and noise is about +/- 5mV around zero.

If you don't have other ideas how to set up filters (bandpass I have and tried all sorts of settings) or start conditions for the integration I would now check for electric interference to see if there are peaks that influence the signals.

Best Regards

Ralf

[altenbach]

---

@Eisbein wrote:

Didn't make it better.

---

No, not for us, anyway!

We still need to stare at a severely truncated picture (now not even showing the FFT part!!). Why are you integrating the waveform (leading to a coercion dot) instead of the Y component? Why are wires going in all directions, some covered up by red circles? Why are you reversing the initial condition? When and where are the terminals for your local variables written?

The FFT will have the right "df" scaling if you correctly carry the "dt" across your code and do the math right. Simple as that.

Please attach a simplified version of your simulation code (with all typical values in all controls) and we can start giving advice. Right now, you are just wasting our time.

[Eisbein]

Hello NoName "Altenbach",

solved by using a tracking filter. Topic can be closed. But:

- If you can't see that these are many FFT's lined up where each point represents the fundamental RMS at certain speeds (an not the input feed), I fear you are wasting my time.

- It worked perfectly without the integration, no matter how many lines go anywhere. Thus my question of start conditions for integration.

- If you feel you're wasting your time, why do you even bother to reply? Don't get it. If you feel that VI's are mandatory, why haven't you just asked instead of offending people?

R.

[altenbach]

---

@Eisbein wrote:

- If you feel you're wasting your time, why do you even bother to reply? Don't get it. If you feel that VI's are mandatory, why haven't you just asked instead of offending people?

---

I am sorry if you feel offended. My posts are about the topic, not about you. Please read them once more with an open mind.

The quality of the responses and the time it takes to find a solution is directly dependent on the quality of the question. Attaching a useful demo VI at the beginning dramatically increases the chance for a quick and good answer by the top contributors. If it takes 24 hours (as in this case) to solve a trivial problem, it is very (very!!!) costly for your employer (at least at my wage, not sure about yours! 😄 ). Even if you found a "solution", maybe it is poor and inefficient. That's all there is to say. Good luck!

(You are talking to someone with more kudos than anyone and one of the three top solution authors. Statistically it is likely that I my advice is sound and potentially better than the answers you have received so far, or the "solution" you figured yourself.).

[mcduff]

---

@altenbach wrote:

---

@Eisbein wrote:

- If you feel you're wasting your time, why do you even bother to reply? Don't get it. If you feel that VI's are mandatory, why haven't you just asked instead of offending people?

---

I am sorry if you feel offended. My posts are about the topic, not about you. Please read them once more with an open mind.

The quality of the responses and the time it takes to find a solution is directly dependent on the quality of the question. Attaching a useful demo VI at the beginning dramatically increases the chance for a quick and good answer by the top contributors. If it takes 24 hours (as in this case) to solve a trivial problem, it is very (very!!!) costly for your employer (at least at my wage, not sure about yours! 😄 ). Even if you found a "solution", maybe it is poor and inefficient. That's all there is to say. Good luck!

(You are talking to someone with more kudos than anyone and one of the three top solution authors. Statistically it is likely that I my advice is sound and potentially better than the answers you have received so far, or the "solution" you figured yourself.).

---

Off topic, but one of my favorites things to find in the forums are VIs that have the MODCA suffix.

mcduff