Feature #587
closed
Mise en conformité de timegen avec SSS-CP-FS-370 (spw timecode value et CTR coarse time)
0%
Description
Rappel d'une partie de l'exigence SSS-CP-FS-370:
The SpaceWire time code contains the least significant bits of the CTR coarse time part.
Dans sa version actuelle, timegen ne prend pas en compte cette exigence.
Updated by paul leroy almost 9 years ago
- Assignee changed from paul leroy to Veronique bouzid
Il n'y a pas à mettre en conformité timegen, il ne gère pas les timecodes. Pour avoir des timecode conformes au TC_LFR_UPDATE_TIME, il va falloir être sioux et bien démarrer les timecodes et bien démarrer les update time.
Ca se fera au niveau SocExplorer avec un script qui va bien.
Si tu émets plusieurs timecode valide avec SpwPlugin0 (3 consécutifs en incrémentant de 1), alors le démarrage des timecodes périodiques commence sur la dernière valeur des timecodes valide + 1.
Updated by Veronique bouzid almost 9 years ago
- Status changed from New to Closed
Paul dit que ce n'est pas utile.
Je mets ici le comportement du LFR quand timegen est utilisé pour se souvenir du comportement.
On observe sur les TM_LFR_HK,
- increment de HK_LFR_UPDATE_TIME_TC_CNT
- increment de HK_LFR_DPU_SPW_TICK_OUT_CNT, HK_LFR_DPU_SPW_LAST_TIMC
- 2 increment de HK_LFR_LE_CNT car on détecte 2 erreurs
HK_LFR_TIME_TIMECODE_IT et HK_LFR_TIME_TIMECODE_CTR
- la derniere erreur détectée est celle de CTR
HK_LFR_LAST_ER_RID: LE_LFR_TIME = 42119, HK_LFR_LAST_ER_CODE: TIMECODE_CTR = 26, HK_LFR_LAST_ER_TIME
Ici dans l exemple on a recu 18 TC_LFR_UPDATE_TIME via timegen avec le timecode valide mais qui ne correspond pas au 6bits les moins significatis du champ CP_RPW_TIME.
Extrait du fichier (2016_02_08-14_15_53-Detail.txt) se trouvant dans /home/validation/data/R3/3.0.0.19/TESTS6UNITAIRES/just_hk/timegen
14:15:23.198608,, TM_LFR_HK, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: HK_ROUTINE = 4, (PACKET_ID=0xcc4), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=17, (PACKET_SEQUENCE_CONTROL=0xc011), PACKET_LENGTH=129, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: HOUSEKEEPING_AND_DIAGNOSTIC_DATA_REPORTING = 3, SERVICE_SUBTYPE: HK_PARAMETER_REPORT = 25, DESTINATION_ID: GROUND = 0, TIME=0x1e4b5f7a01ec, PA_LFR_HK_REPORT_SID: LFR_HK_SID = 1, HK_LFR_MODE: STANDBY = 0, HK_LFR_DPU_SPW_ENABLED: ENABLED = 1, HK_LFR_DPU_SPW_LINK_STATE: RUN = 5, SPARE=0x0, HK_LFR_SC_POTENTIEL_FLAG: ON = 1, HK_LFR_MAG_FIELDS_FLAG: OFF = 0, SY_LFR_WATCHDOG_ENABLED: ENABLED = 1, HK_LFR_CALIB_ENABLED: DISABLED = 0, HK_LFR_RESET_CAUSE: POWER_ON = 1, SY_LFR_SW_VERSION_N1=3, SY_LFR_SW_VERSION_N2=0, SY_LFR_SW_VERSION_N3=0, SY_LFR_SW_VERSION_N4=19, SY_LFR_FPGA_VERSION_N1=1, SY_LFR_FPGA_VERSION_N2=1, SY_LFR_FPGA_VERSION_N3=89, H*K_LFR_UPDATE_TIME_TC_CNT=18, HK_LFR_LE_CNT=36*, HK_LFR_ME_CNT=0, HK_LFR_HE_CNT=0, H*K_LFR_LAST_ER_RID: LE_LFR_TIME = 42119, HK_LFR_LAST_ER_CODE: TIMECODE_CTR = 26, HK_LFR_LAST_ER_TIME=0x1e4b5f7a0002*, HK_LFR_DPU_SPW_TICK_OUT_CNT=19, HK_LFR_DPU_SPW_LAST_TIMC=19, , HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=0, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=18, HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=18,