...
Here I collect the results of the testing I am performingperformed, comparing the output generated by the old ft2Util code with the output generated by my code.
...
Attitude and orbital quantities
The maximum difference is of the order of ~ 2%, and it is in QSJ_3. QSJ_3 is the Z component of the vectorial part of the attitude quaternion. Usually the attitude quaternion is taken directly from the ATT message in the Magic 7 file. Those messages are issued by the spacecraft 5 times per second. Anyway, there are cases when there is no ATT message corresponding to a particular time interval, thus the codes have to interpolate (or extrapolate). This usually can happen at the very beginning of a run, or because of gaps in the Magic 7 file. The very small differences between the two codes arises arise mainly from two different strategies adopted for the interpolation/extrapolation: the old code uses only ATT messages arriving in sync with an ORB message (that is, one time per second), discarding the others; the new code, instead, uses all the available ATT messages. Thus, the new code should provide better interpolation/extrapolation. Anyway, the differences are really smalltiny, and I can't think of any application where they could really matter...
...
I show here only the results concerning the live time. The results related to the other quantities are very similar to the previous test. :
| Gallery | ||||||
|---|---|---|---|---|---|---|
|
In the first panel there is the fractional difference for LIVETIME: as you can see, there are differences up to a few percent (~5%). The second panel shows a zoom of a region: we can clearly see a small growing trend inside each and every run, and some occasional larger "flares". As you can see in the third panel, those flares seem symmetrically distributed around the zero line, with a upward fluctuation followed by a downward fluctuation of the same amount. But, two fluctuations can combine giving a third fluctuation which is the opposite of the algebraic sum of the former two. This also means that this should NOT usually be a problem for analysis using 30s FT2 files, or in general spanning more than few seconds, because those problems will cancel out.
To investigate the issue, I've produced a Digi file where I've overwritten the livetime counter in each event with its elapsed time counter. This means a dead time of zero, thus every bin in the FT2 file (except the first and the last one) must have LIVETIME = 1. Then, I run both codes on this Digi file, with the following results:
...