I'm taking burst measurements followed by FFT analysis and have noticed an apparent imprecision in burst measurement timing. In the following example, I'm taking a 8192 point sample with 521 microseconds between each measurement. That 8192 point array is then processed using FFTSpa into a 4096 point array. By my calculations (calculations which have been working for smaller samples with much larger bin sizes for years), this gives a bin spacing of 0.2343 Hz.
I'm measuring the AC magnetic field, and I'm noticing that several signals and harmonics of known frequencies are showing up with slightly higher peaks than expected. Here are a few examples from an average of 10 of these FFTs. The bin frequency is on the left, with the real component of the FFT value for that bin on the right. These are a few bins around the 360 Hz, 420 Hz, and 540 Hz harmonics of the 60 Hz power line signal, as well as bins around a 380 Hz signal emanating from a large testing coil in our lab.
The samples were processed through a Kaiser filter before the FFT was applied, which explains the width of the FFT results.
Frequency (Hz) FFT real component (mV)
359.8848 0.1620043
360.1191 0.4728214
360.3534 0.6687906
360.5877 0.4763885
360.822 0.1561748
379.8003 0.1088725
380.0346 0.3416967
380.2689 0.5107554
380.5032 0.3775212
380.7375 0.1309946
419.8656 0.02084613
420.0999 0.0783665
420.3342 0.139572
420.5685 0.1265392
420.8028 0.05741018
421.0371 0.01182784
540.0615 0.001485316
540.2958 0.004277254
540.5302 0.006073155
540.7645 0.004485478
540.9987 0.001650237
Glancing at the numbers shows that the peak values fall later and later than expected in the spectrum as we progress to higher frequencies. In fact, using the 380 Hz signal - which is rather nicely centered in this result around the 380.2689 bin - as a guideline, I estimate a timing/frequency error of approximately 0.1% - multiplying the calculated frequency bins by 0.999 moves each of the peaks to a much more logical location.
With that long explanation - any thought on what could be causing this, or any potential solution? If every CR1000 had this identical problem, I could just correct as explained, but my concern would be different timing errors in different dataloggers. Any suggestions?
I'm using OS17, if you're curious.
Thanks,
Benjamin
This should not happen. Can you please show us what instruction you are using to do the burst measurement and also confirm whether the datalogger compiles the program in pipeline mode or sequential mode, please.
Hello,
The program was compiling in sequential mode, since I have to use some logic to determine what scale to measure at. However, I created a modified version this morning with no conditional statements and compiled it in pipeline mode; results were approximately the same (I can send you the numbers if you want), with similar apparent timing accuracy issues.
The burst measurement instruction is:
Scan(5,Sec,0,1): VoltDiff(signal_raw,8192,mV25,-1,False,521,0,1,0): NextScan
The testing program itself is quite simple. I copy it below, without variable declarations or the 4096-point half-Kaiser window data points which comprise the bulk of the code. FFT_Table simply saves the values of all FFT bins. I can send the full code in a file if that would be of interest.
BeginProg
WriteIO(AllPorts,ZCode) ' Sets external multiplexer to read the correct sensor
For f = 1 To 4096
Read Kaiser(f) ' Reads in first half of the Kaiser window
Next f
For f = 4097 To 8192
Kaiser(f) = Kaiser(8193 - f) ' Sets second half of the Kaiser window
Next f
Scan(5,Sec,0,1): VoltDiff(signal_raw,8192,mV25,-1,False,521,0,1,0): NextScan
For f = 1 To 8192
signal_kaiser(f) = signal_raw(f) * Kaiser(f)
Next f
FFTSpa(Z_FFT, 8192, signal_kaiser, 521, usec, 1)
For f = 1 To 4097
CallTable FFT_Table
Next f
done = true
EndProg
FYI: we are investigating this finding. What I can tell you so far is that if there is an issue with timing, it is not as simple as a 0.1% error that applies across the board, for all types of FFTs and sampling strategies.
We'll publish an update here when we have finished testing.
I created a program from your template, but without the Kaiser windowing function.
I hooked up a Function Generator and tested the output.
I test several 60 Hz haromonic frequencies and all fell into the right bins. For example, the 540 hz signal fell into bin # 2307. Of course this was the fundamental frequency, and I can only lower the peak to peak amplitude to 10 mV.
Have you tried hooking up a function generator and testing yours to insure the signal that is being measured? Also without your windowing function to see if this is the cause?
Hi,
Could you please explain how you're deciding which bin a signal should fall into? I have been considering the bins to be defined by center frequencies - is this correct? For example, for the given parameters of 8192 points sampled at 521 microsecond intervals, I expect the Nyquist frequency to be 959.6929 Hz. There will be 4097 bins, with bin 1 at 0 Hz and bin 4097 at 959.6929 Hz. The bin interval is then 959.6929 / 4096, or 0.2343. The frequency for bin #2307 would be (2307-1) * 0.2343, or 540.296 Hz. Bin # 2306 would be the correct center for the 540 Hz frequency by my calculations, falling at 540.062 Hz.
I can try some of your other suggestions; in the meanwhile, can you help me understand our discrepancy in bin numbering?
Thanks,
Benj
I stand corrected. I was incorrectly allowing the first two bins to be the DC and then the Nyquist, then the following frequency bins.
But it is the DC (range centered around 0 Hz from -0.11715 to + 0.11715) then the frequency bins, with the Nyquist in the last bin.
The range of each bin would be [(Bin#-1) x 0.2343 - 0.11715] to [(Bin#-1) x 0.2343 + 0.11715].
So my test did show the 540 Hz input signal in the wrong bin.
I am thinking that the actual time between sample is not really 521 uS. I know that the clock resolution is 540 nS, so I tried 540 uS for the sample frequency, but still saw errant data.
* Last updated by: TweedleDee on 3/29/2010 @ 4:20 PM *
Behind the scenes (TweedleDee please speak to Larry) we have looked at this and have identified a couple of issues which we can improve upon. The issues we have found are only significant when you push the scan rate to the limit, as has been done in this case. The improvements are still being worked on and will be in our next OS release.
If benjaminc would like to email me we will give more details by PM. My email address is:
andrew dot sandford at campbellsci dot co dot uk
Is there a conclusion to this, or a recommendation on how to steer clear of the problem area? I am also trying to push the CR1000 to the limit, but would like to know where the practical limit is.
Anton
Some issues were resolved in terms of the resolution on internal clocks. The next release of operating systems has a couple of improvements.
The main problem is caused by the fact that the logger samples at a frequency that is close to but not exactly the specified interval entered when put in an integer value of microsec. In the next OS (due out within two weeks), you can enter the actual sample period as a float and we will give details of how to calculate the period interval.