FFTPower routine units, units handling, and multiple FFTUtil routines
Opened this issue · 3 comments
Keith pointed out issues with the FFTPower routine with Cluster data, where transitions and waveform cadence changes were not handled properly. These were resolved and released in Autoplot v2023a_2, but some issues still remain.
The output of FFTPower will be modified with a kludge when the waveform units are mV/m to make the output be (V/m)^2/Hz. This is the one special case where the FFTPower output has units, usually the output is dimensionless. See https://github.com/das-developers/das2java/blob/main/QDataSet/src/org/das2/qds/util/FFTUtil.java#L207
It might be better to report a unit of "(wavUnits)^2 * cadenceUnits" so that there is always something, but note that there is an SIUnits class which does the math. I've always wanted to use this, but I know it will cause all sorts of new problems.
The FFTPower library says the window weight is not accounted for and then three lines later a comment says it is. I believe it is, but this should be verified.
There is a check for fixed cadence within a packet, checking that the entire packet length (in time) is consistent with the length (of time) between the first ten measuments. This continues for translation, but drops the non-fixed-cadence packet when there is no translation.
Last, there are three FFTUtil codes! Two within QDataSet, one in DasCore. I'm pretty sure these all have similar static routines, and one should be used and the others deprecated. (The extra one in QDataSet can probably be removed, since I don't think any third parties are using it.)
- units should always be reported
- window weight normalization
- check for one cadence in packet which continues for translation but not without translation
- multiple FFTUtil codes
I verified the window weight normalization and cleaned up the comments. Also I removed the inconsistent logic for cadence changes when translation is used.
Keith pointed out that there was still an issue with translation, and the problem was that the offset was included in the translated xtags, and the code careless assumed that the first bin was the binsize.