0

I'm doing a project where I'm aquiring accelerometer data from a custom designed measurement system. The measurement system is an accelerometer connected to a Raspberry pi 3, running a Python script which samples data and writes them to a csv file at occasional times. The csv files are then imported to a computer and run FFT analysis in matlab.

I would like to calculate an average of the FFT result from several datasets. This is to be able to determine if there is any relationship in frequency and amplitudes between the different datasets.

When I run the measurement system in a python script and Raspberry Pi 3, the frequency stability cannot be said to be the best. In the python script I have set the sample rate to be 615 hz, which the Pi can partially maintain until it has to write data to the csv file. The script is currently set to write to file when the buffer is 615 samples in length, effectively 615 * 4. Due to this procedure the time between two samples "drifts" from 1.6 ms to approximately 20 ms when I run a csv write. The average sample rate determined by matlab seems to be approximately 600 hz, for most of the data sets I've analyzed so far. Due to the inconsistency of sample rate in the python script, and fact that I run samples with various lengths, I have frequency bins of various sizes when I compare the different data sets.

I have tried to investigate if the "sample rate drift" could give corrupted FFT results, without any significant findings. The FFT results seems to be partially ok, but I don't have any reference to compare them to. Have anyone experienced any similiar cases with FFT with a "non-continous" sample rate?

Are there any suggestions for how I can calculate an average of multiple FFTs, when the datasets differ slightly in "detected sample frequency" and sample length?

Petter
  • 21
  • 4
  • look into normalizing your raw data before performing fft ... also fft works best when its given an even power of 2 number of samples ... 512 is good ... as is every doubling namely 1024 and 2048 ... etc ... these two basic changes will greatly improve the quality of any fft result ... also I suggest you get intimate with this by synthesizing sets of raw data which you can play with to enhance your fft kung fu – Scott Stensland Feb 25 '19 at 19:27
  • I'm using an example from Midè as a mainframe for my FFT. The example uses an accelerometer in a cars engine bay, and FFT's the signal. I'm gathering data from a cars windshield. In the Midè example the fft result is normalized, and multiplied by two: xdft = fft(x); xdft = 1/length(x).*xdft; %Normalize xdft(2:end-1) = 2*xdft(2:end-1); I'll dig into the even number of samples case, to see if it enhances my fft result. As I stated in the main text I have several data sets available, from several cars and drivers, so I'll try to stick with the data sets I've already gathered :) – Petter Feb 26 '19 at 11:39
  • Non-continuous data sounds like a bad thing. Unfortunately more data processing might not be a solution if it further slows down your system, but I can think of a interpolation of your time data to get regular sampling as one possible solution, provided you have the exact sampling times. Do you have an example dataset? – Buck Thorn Feb 26 '19 at 20:46
  • I've talked with a signal processing associate professor at my university. His response to the sample rate drift was that a polynomial interpolation could make the data appear to be sampled at regular intervals. According to him, drifting could give the greatest impact in frequency components in the upper frequency layer of my fft, and potentially lead to aliasing. The lower frequency layer would be more pristine. As of now it doesn't seem like I have any dominant frequency components in the upper spectra, so hopefully my measurements, which should be below 100 hz, are unaffected. – Petter Feb 27 '19 at 13:35
  • As a further comment to TryHard; all the fft processing is done post, on a pc w matlab. I'm a little uncertain what you mean by the claim that adding more data processing will slow down the speed even further. The claim is correct regarding real-time processing on the PI, but not as relevant for post processing. The Python scripts writing operation is "optimized" by letting it write a string containing a datetime object, and 6 H&L bitshifted ADC data for XYZ axis. This string is appended to a list, and when the list reaches a certain value the entire list is appended to the CSV file. – Petter Feb 27 '19 at 15:42
  • I think you can find your answer here https://stackoverflow.com/questions/22583391/peak-signal-detection-in-realtime-timeseries-data/56451135#56451135 – Alaaldin Jan 22 '21 at 14:38

0 Answers0