Description of the issue
Looking at a day of L1b MAG BM data we can see slight jitter in the timestamps. This is unexpected and unexplained as we think the hardware does not exhibit this jitter so we need to understand the cause. Perhaps the clock correction in spice? Another issue #2464 may seem related but that has a maximum error on it of 0.000015s (1/65535). This jitter in this ticket is larger at max of 0.0003s
NOTE: This issue is lower priority than other bugs in the MAG backlog
Lots of the following is based on analysis by Tim H:
This is MAGo:
This is a histogram of the differences.
You’d expect this to be more one sided if the instrument clock were drifting with respect to the spacecraft. This spread is perhaps not enormous, it is a few percent and corresponds to a rotation error of under 0.01deg. The larger jumps go both backwards and forwards in quick succession which is odd. These are large enough to be of interest, being around 10% of the cadence. Perhaps they are symptoms of the spacecraft clock being corrected?
It would be helpful to start with a similar analysis at packet level (L0 and l1A?) and then trace the spource of the jitter assuming it is after that.
Expected vs Actual behavior
Would expect timestamps to be more continuous with no/smaller jitter
Code Snippet (If applicable)
Converting times from the CDF files like this in MTALAB, which preserves the time stamps more accurately, but is slower, than what we normally use:
tPrecise=datetime(spdfcdfread(FileName, 'Variables', 'epoch','CombineRecords',true,'CDFEpochToString',true),'Format','yyyy-MM-dd''T''HH:mm:ss.SSSSSSSSS');
The fast but inaccurate way is this:
tFast=datetime(spdfcdfread(FileName,'Variables','epoch','ConvertEpochToDatenum',true),'ConvertFrom','datenum');
Description of the issue
Looking at a day of L1b MAG BM data we can see slight jitter in the timestamps. This is unexpected and unexplained as we think the hardware does not exhibit this jitter so we need to understand the cause. Perhaps the clock correction in spice? Another issue #2464 may seem related but that has a maximum error on it of 0.000015s (1/65535). This jitter in this ticket is larger at max of 0.0003s
NOTE: This issue is lower priority than other bugs in the MAG backlog
Lots of the following is based on analysis by Tim H:
This is MAGo:
This is a histogram of the differences.
You’d expect this to be more one sided if the instrument clock were drifting with respect to the spacecraft. This spread is perhaps not enormous, it is a few percent and corresponds to a rotation error of under 0.01deg. The larger jumps go both backwards and forwards in quick succession which is odd. These are large enough to be of interest, being around 10% of the cadence. Perhaps they are symptoms of the spacecraft clock being corrected?
It would be helpful to start with a similar analysis at packet level (L0 and l1A?) and then trace the spource of the jitter assuming it is after that.
Expected vs Actual behavior
Would expect timestamps to be more continuous with no/smaller jitter
Code Snippet (If applicable)
Converting times from the CDF files like this in MTALAB, which preserves the time stamps more accurately, but is slower, than what we normally use:
The fast but inaccurate way is this: