Analysis of PCSS Timing Handling

Introduction

Herschel/PACS FM-IST measurements at the He-II cryo stage have been carried out between 24th and 28th August 2008. These comprised SFT, SPT, EMC test, FFT. During the analysis of the data obtained during these measurements, the time key of the diagnostic HK data turned out to be unreliable. Here, I summarise some the most important issues of this finding.

Data Analysis

For the check of the synchronisation of the PACS chopper trigger with the SPEC detector readout, we used a diagnostic HK sampling frequency of 256 Hz and 1000 Hz. I selected measurement with the lower frequency for this summary. The TM file is FIST_SPT_Spec707a_choppDetecSync_redundant_20080828_03.tm. Furthermore, the Chopper SFT carried in open loop is used during this investigation. The referring TM file is FIST_SFTHeII_Chopper_002_20080824.tm. I also investigate the impact on the time keys of the two PCSS HK import classes getRawMeasures and ValuesExtractor.getDiagnosticValues. Finally and as a comparison, I investigated the time keys extracted from the data DECMEC header.

Chopper SFT

This Figure demonstrates the time information extracted from the 1kHz diagnostic HK for every data point and separated into the two available PCSS import classes. It shows that ValuesExtractor.getDiagnosticValues produces a non-continuous sequence time information. At some point, even two following data points have a negative time progression. The time jumps backwards. This can lead to confusing results when analysing the HK data. The (deprecated) class getRawMeasures does not seem to have this problem.

The following figure displays, how the time data diverge from a linear fit to the time information per HK data packet. Again, we see that the getRawMeasures class produces less scatter than the ValuesExtractor.getDiagnosticValues class, where a deviation by +/- 2 ms is found. This is quite a lot when trying to assess the performance of mechanisms on a millisecond time scale. However, the latter seems to behave in a much more orderly way. Apparently, the time stamps are lagging behind and are corrected by a reset every 910 readouts (on average). This 0.91s for the 1kHz diagnostic HK.

Chopper Synchronisation

The main difference to the SFT mentioned in the previous section consists of the SPEC detector data that are obtained parallel to the diagnostic HK sampled at 256 Hz. With this measurement, the two HK import classes produce a different time information. While getRawMeasures produces a continuous increment of time, ValuesExtractor.getDiagnosticValues shows regular resets to a start value reflecting the reset of the general satellite time normal monitored by the HK parameter DM_OBT_COUNT.

The previous figure again shows jumps in the sequence of the time stamps, just as seen for the Chopper SFT. However, there was no incident of negative time evolution. It can be speculated that this might be caused by the reduced HK sampling rate. The following figure shows again the difference of the time information from a linear fit. Here, the scatter of the two HK import classes produce the same data scatter amplitude, however getRawMeasures seems to lead to a more erratic picture. The ValuesExtractor.getDiagnosticValues produces frequent outliers of an amplitude of +4ms. Apart from these outliers, the time information appears to behave well with only a small scatter of about +/- 10 microseconds. The slight slope is a result of the linear fit that also included the 4ms outliers.

The time key extracted from the the detector data (DECMEC header), as shown in the following figure, behaves very well without any apparent irregular jumps. We observe only a very small scatter of the order of +/- 0.36 microseconds. This scatter apparently consists of 4 discrete values which points to digitalisation noise and small rounding uncertainties. This seems very comparable, what was seen in the diagnostic HK when neglecting the strong outliers there.

Attachments

There are 5 attachment(s) stored for this page.