Project

General

Profile

Bug #94

PA_LFR_ACQUISITION_TIME de TM_LFR_SCIENCE_* erroné

Added by Gerald Saule over 7 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
-
Start date:
17/03/2014
Due date:
% Done:

0%

Estimated time:
revision:
r109

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

2014_03_17-11_24_30-Synth+.txt (423 KB) 2014_03_17-11_24_30-Synth+.txt Gerald Saule, 17/03/2014 01:33 PM

History

#1 Updated by Gerald Saule over 7 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

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

On calcule les délais:
  • 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

#2 Updated by paul leroy almost 7 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

#3 Updated by bruno katra about 6 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF