Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Navigation
- Simcenter
- Forums
- Blogs
- Knowledge Bases

- Siemens PLM Community
- Simcenter
- Testing Forum
- LMS Test.Lab: FFT analysis 1 Hz

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content

01-28-2016 02:44 AM

Hello,

after you exctracetd the appended file: sinus.zip you can find serveral synthetically sinus forms: 1 Hz, 30 Hz, 40 Hz and 50 Hz with a time axis in the first colunm. You can directly importet this ASCII-file to LMS Test.Lab.

If you make a FFT with the FFT icon you get logical results.

Now you make the same with: Time Data Processing

Measurement mode: Stationary

Duration: 200 s or something else

Acquisition rate: 1 (very imporant)

Number of averages: is automatically calculated

Averaging type: linear averageFS Acquisition: Use fixed sampling

Spectral lines: 2048 (for example)

Compute fixed sampled Data (activate)

Function: Spectrum

Window: Uniform

Final weighting: no change

You get also plausible results for all frequencies.

Now you change **only** the acquisition rate from 1 to 2!

After the new calculation: everyone frequencies calculation (30 Hz, 40 Hz, 50 Hz) seems ok except 1 Hz! I do not know, what went wrong in this calculation!

If you change only the acquisition rate to 3, 5 or 10! Always the same results! The frequencies calculation of 30 Hz, 40 Hz and 50 Hz are o.k., but the frequency calculation of 1Hz is completely gone wrong.

Where is the error?

In the time history you can see, that the frequency of 1 Hz is correctly importet!

I hope you can help me!

Best regards

Kurt

Labels:

3 REPLIES

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content

01-28-2016 03:52 AM

Hi,

I cannot comment on the FFT calculation of LMS Test.Lab, but regarding the ASCII format I have one remark: you use the delta t of +2.0833262892384E-04 s, which will lead to a sampling rate of 4800.01623 Hz. Maybe you want to try whether the results change if you specify the rate in the ascii header:

RATE = [ 4800, 4800, 4800, 4800, 4800 ]

and remove the line "DELTA = ..."

or use a more precise delta t

DELTA = [ +2.0833333333333E-04, +2.0833333333333E-04, +2.0833333333333E-04, +2.0833333333333E-04, +2.0833333333333E-04]

Regards

Holger

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content

02-04-2016 04:46 AM

Hi,

In this case, it is irrespectively of whether the sampling rate is 4800 or 4800.02 Hertz. Rather, it is to find out why the calculation at 1 Hz is faulty.

For a better understanding I have attached a file (Example.zip). In this appended file you find two picture. One (2048.bmp). I have created with the following parameter:

Measurement mode: Stationary

Tracking Method: Time

Duration: 200 s

Acquisition rate: 1

Number of averages: is automatically calculated

Overlap: 50%

Averaging type: linear averageFS Acquisition: Use fixed sampling

Spectral lines: 2048 (for example)

Compute fixed sampled Data (activate)

Function: Spectrum

Window: Uniform

Final weighting: no change

Here one can clearly see that all frequency values within the normal range.

Now I have change the acquisition rate from 1 to 10. **Only** the calculation of the FFT at 1 Hertz is totally wrong (see 2048_10.bmp).

What happened?

Can you help me?

Kurt

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content

02-04-2016 05:10 AM - edited 02-25-2016 04:53 AM

Hi Kurt,

If you need to get your answer quickly you can always contact our customer support team at GTAC. They will be more than happy to answer your question !

The average rate you have selected for a 1Hz signal started to create overlap (no in the case of 1 avg/s - that's the perfect case with 0 overlap). By increasing the averaging rate you increase the overlap between the frames. What happens is that by averaging those frames over the full run you finally include a signal which is shifted in phase by 180 degrees therefore introducing your error. I suggest you try it out with tracked in time processing to observe the result (both amplitude and phase) with different settings.

Follow Siemens PLM Software

© 2017 Siemens Product Lifecycle Management Software Inc