Datation algorithm
==================
== Introduction
We have problem to set timetags for science data.
We tried to use the following algotithm, relative to various telemetry levels.
=== Telemetry levels
The BEPI telemetry data is encapsulated in various data levels :
* SDTP packet
* CCSDS packet
* Mission or HSK packets
==== SDTP frame structure
[cols="20%,80%"]
|===
| SDTP header | CCSDS packet
|===
The SDTP header contains a datetime, BCD encoded, with :
yyyyddddhhmmssmmmmmm
==== CCSDS frame structure
[cols="20%,40%,40%"]
|===
| CCSDS header | packet #1 | packet #2...
|===
The CCSDS header contains datetime information :
* An unsigned 32 bits integer,
* that gives offset from an unknown origin,
* each tick corresponding to 1s/32 = 31.25 ms
==== HSK packets
[cols="33%,33%,33%"]
|===
| Monitored HK data | User HK data | Software HK data
|===
Each HSK data is encapsulated in a single CCSDS frame, himself encapsulated in a single SDTP frame.
There is no specific header that contains datetime information in HSK packets.
So we can consider using the SDTP header timing information to compute CCSDS timing counter origin,
supposing they correspond to the same timestamp.
==== Mission header (science data)
[cols="20%,80%"]
|===
| Science packet header | data
|===
Several science data packets should be encapsulated in a single CCSDS frame,
Each science packet header contains datetime information :
* an unsigned 32 bits integer
* that gives offset from an unknown origin
* each tick corresponding to 1s/512 ≃ 1,95.. ms
=== Algorithm
We are using HSK data to recompute the origin of time counters, supposing that the timetag given in SDTP header
of each HSK packet correspond to the same timetag that the CCSDS counter.
From the SDTP header, we can extract a datetime yyyy/dddThh:mm:ss.mmmmmm
From the CCSDS header, we can extract a counter ccsds.time, and then recompute the origin of this counter :
origin = yyyy/dddThh:mm:ss.mmmmmmmm - ccsds.time / 32s
Then, we can use this time origin, considering it's the origin of each CCSDS timetags, but also of each science data packet.
We can recompute timetags for science data, using :
timetag = origin + science.time / 512s
=== Example of MEA1 data for 2017/02/03
==== Recompute origin of ticks
The first HSK packet of MEA1 data for 2017/02/03 comes with an SDTP header datetime :
TIME (SDTP) : 2017-034T12:06:58.854437Z
It encapsulate a CCSDS packet, with a counter :
TIME (CCSDS) : 0007D8D9 514265 16070.781
First value in hexadecimal, second one is decimal conversion, and the last is in seconds.
So, we can recompute origin of CCSDS time :
origin = 2017-034T12:06:58.854437Z - 514265 / 32s
= 2017-034T12:06:58.854437Z - 16070 s
= 2017-02-03T07:39:08
[NOTE]
====
We can recompute the counter origin with any HSK packet, not only the first one.
HSK data have a periodicity of 8s, that we found both is SDTP timetags and in CCSDS counter ticks.
Computation of ticks origine gives roughly the same result (+/- some ms)
====
==== Recomputing science data timetags
The first science packet of MEA1 data comes with :
TIME (TI0) : 0096CC16 9882646 19302.043
We can recompute time :
timetag = origin + 9882646 / 512s
= origin + 19302.043s
= 2017-02-03T13:00:50
This algorithm seems to works, except for a couple of days.
=== Problem for MEA1 data for 2014/11/16
The first HSK MEA1 data packet comes with :
TIME (SDTP) : 2014-320T00:00:00.832437Z
TIME (CCSDS) : 01229759 19044185 595130.781
We can recompute ticks origin :
origin = 2014-320T00:00:00.832437Z - 595130.781 s
= 2014-11-09T02:41:09
The first SCI data packet comes with :
TIME (TI0) : 113AC214 289063444 564577.062
If we recompute :
timetag = origin + 564577.062 s
= 2014-11-15T15:30:46.281000
[role='red']
--
Problem: the science packet is not in time range 2014-11-16T00:00:00 - 2014-11-17T00:00:00
--
Full check : link:/documents/PB_DATATION/CHECK_TIME.log[]
Found problems : link:/documents/PB_DATATION/CHECK_TIME.pb[]
