Mathematical Issues in OSD Algorithm

[jones139]

I am working on some improvements to the OSD algorithm to improve sensitivity to movements perpendicular to the direction of gravity.
In doing this I have been comparing the testRunner.py output to the OSD android app output for the same acceleration input data and have found some mathematical issues which we should resolve at some point. (It will need to be part of a major release because it will need some of the threshold settings to be updated when the calculation is changed.
The issues I have identified are:

• The Spectrum power is supposed to be the average power over the whole spectrum. In practice we add up the total over all FFT bins (except the DC bin (0)), then divide by mNSamp/2. We should really divide by int(mNSamp/2), which gives a much larger calculated spectrum power. This will affect the roiRatio so we will need to change the Alarm Ratio Threshold to compensate.
• The Spectrum power is calculated as the average up to the frequency cutoff value. The android app has this hard coded as 12Hz, It should really be sampleFreq/2, (12.5Hz).
• The fft magnitude is actually magnitude^2 - we should square root it so that the FFT values are in milli-g. This again is likely to affect the alarm ratio threshold value.
• The issue I am working on is that if the acceleration in a particular axis crosses zero (which it will do if it is not affected by gravity), its frequency is doubled (bridge rectifier effect), but if gravity is acting in that axis, it is unlikely to cross zero so the frequency is correct. I think that adding an offset to all the axes will avoid the zero crossing issue and improve the sensitivity in axes that do not contain a significant gravity component.