Bug #94
closed
PA_LFR_ACQUISITION_TIME de TM_LFR_SCIENCE_* erroné
0%
Description
Le champ PA_LFR_ACQUISITION_TIME de TM_LFR_SCIENCE_SBM1_SWF_F2, est vu une fois erroné, de façon très exeptionnelle (et difficilement reproductible).
11:19:29.402643, TM_LFR_SCIENCE_NORMAL_SWF_F2, TIME=0x80000dcb9dc8, PA_LFR_PKT_NR=1, PA_LFR_ACQUISITION_TIME=0x80000db68069
...
11:24:29.404096, TM_LFR_SCIENCE_NORMAL_SWF_F2, TIME=0x80000ef79e87, PA_LFR_PKT_NR=1, PA_LFR_ACQUISITION_TIME=0x80000ee70069
Calcul des deltas:
PC: 300,001453s
TIME: 300,002914429s
PA_LFR_ACQUISITION_TIME:(0xdb68069-0xee70069)/0x10000=304,5s
(le pb est surveillé par la fonctionnalité "sss_cp_eqs_070 = tm_lfr_hk_period" de ./lfrverif/common/verif_fields.py)
La période est fonctionnellement correcte; les mesures faites par l'horloge du PC (potentiellement dégradées par d'éventuelles variations de charge CPU), ainsi que le champ TIME, sont très satisfaisants.
Aucun autre point suspect de périodicité n'est vu durant ce test. Par exemple, pendant la plage [11:04:09.936862-11:14:23.134139[ (en SBM1): les incréments de PA_LFR_ACQUISITION_TIME sont bons:
pour TM_LFR_SCIENCE_NORMAL_CWF_F3 (168s),TM_LFR_SCIENCE_NORMAL_SWF_F[0-2] (300s), TM_LFR_SCIENCE_SBM1_CWF_F1 (0.65625s) (les ASM et BP n'étant actuellement pas générés).
NB: Issue à rapprochée de Bug #60 et #64 ?
Contexte:
LPPMON Version=0.2.2 Branch=default Changeset=835955994d5f
Carte mini-LFR:LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)
Vhdl: mini-lfr_0.0.15
Soft: 1.0.0.1 (variante sur carte finale)
Brique Star-Dundee S/N 46120065.
TEST CASE = SVS_0042
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1
Files
Updated by Gerald Saule over 10 years ago
- Subject changed from PA_LFR_ACQUISITION_TIME de TM_LFR_SCIENCE_NORMAL_SWF_F2 erroné to PA_LFR_ACQUISITION_TIME de TM_LFR_SCIENCE_* erroné
- revision changed from r104 to r109
A chaque salve de (huit) TM_LFR_SCIENCE_BURST_CWF_F2, PA_LFR_ACQUISITION_TIME est incrémenté de 0xA8000 (ie 10.5s). C'est tout à fait correct.
(confirmé sur 17 périodes)
Malheureusement, il y a une anomalie dans ce schéma
On calcule les délais:13:13:14.105561, TM_LFR_SCIENCE_BURST_CWF_F2, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=142, (PACKET_SEQUENCE_CONTROL=0xc08e), PACKET_LENGTH=4051, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, TIME=0x800004707f27, PA_LFR_SID_PKT: SC_B_CWF_F2 = 2, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS1_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS2_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS3_ENABLED: ENABLED = 1, SPARE: 0x0, PA_LFR_ACQUISITION_TIME=0x800004675000, PA_LFR_CWF_BLK_NR=336
...
13:13:24.605457, TM_LFR_SCIENCE_BURST_CWF_F2, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=149, (PACKET_SEQUENCE_CONTROL=0xc095), PACKET_LENGTH=4051, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, TIME=0x8000047aff1a, PA_LFR_SID_PKT: SC_B_CWF_F2 = 2, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS1_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS2_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS3_ENABLED: ENABLED = 1, SPARE: 0x0, PA_LFR_ACQUISITION_TIME=0x800004708000, PA_LFR_CWF_BLK_NR=336
...
13:13:35.105404, TM_LFR_SCIENCE_BURST_CWF_F2, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=157, (PACKET_SEQUENCE_CONTROL=0xc09d), PACKET_LENGTH=4051, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, TIME=0x800004857f1a, PA_LFR_SID_PKT: SC_B_CWF_F2 = 2, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS1_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS2_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS3_ENABLED: ENABLED = 1, SPARE: 0x0, PA_LFR_ACQUISITION_TIME=0x8000047b0000, PA_LFR_CWF_BLK_NR=336
- 13:13:24.605457 - 13:13:14.105561 = 10,499896s
- (800004675000₁₆−8000045b8000₁₆)÷10000₁₆=11,8125s
Le champ PA_LFR_ACQUISITION_TIME a un exces de 0x15000
L'analyse des salves suivantes montre à nouveau des périodes nominales de 10,5s.
On en déduit :
-Que le mécanisme de datation des données (recopie instantannée du le temps interne) ne semble pas en cause.
-Qu'il s'agit d'un dérive malencontreuse du temps interne.
Le fait d'avoir un écart non quelconque (0x15000) pourrait être une piste d'investigation.
LPPMON Version=0.2.2 Branch=default Changeset=835955994d5f
Carte mini-LFR:LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)
Vhdl: lfr_0.0.15
Soft: 1.0.0.3
Brique Star-Dundee S/N illisible.
TEST CASE = SVS_0022
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2
RPW-SYS---ICD-00067-LES_Issue2_Rev2_RPW_IDB_Parameter_Definition
Updated by paul leroy almost 10 years ago
- Status changed from New to Resolved
- Assignee changed from paul leroy to Veronique bouzid
rejouer les tests sur:
FSW >= 2.0.2.1
VHDL >= x.1.57
Updated by