Bug #72
closed
Perte de périodicité sur ultime TM_LFR_SCIENCE_SBM2_CWF_F2
0%
Description
Les TM_LFR_SCIENCE_SBM2_CWF_F2doivent être générées à la fréquence de 256.0Hz. Ainsi, les données étant bufferisées, on attend uns salve de 8 TM_LFR_SCIENCE_SBM2_CWF_F2 toutes les 10.5s.
On observe très précisement cette cadence (sur les 36 périodes précédentes), sauf dans le cas ci-dessous:
17:18:53.066229, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007c000a8
17:18:53.074801, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007c150a8
17:18:53.078671, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007c2a0a8
17:18:53.082048, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007c3f0a8
17:18:53.085287, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007c540a8
17:18:53.101314, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007c690a8
17:18:53.105723, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007c7e0a8
17:18:53.109579, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007c930a8
17:18:53.93814, TM_LFR_HK
17:18:54.938771, TM_LFR_HK
17:18:55.938731, TM_LFR_HK
17:18:56.938748, TM_LFR_HK
17:18:57.938755, TM_LFR_HK
17:18:58.938711, TM_LFR_HK
17:18:59.938724, TM_LFR_HK
17:19:00.53456, TM_LFR_SCIENCE_NORMAL_CWF_LONG_F3
17:19:00.939025, TM_LFR_HK
17:19:01.938561, TM_LFR_HK
17:19:02.93855, TM_LFR_HK
17:19:03.556298, TC_LFR_ENTER_MODE (CP_LFR_MODE=0), CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TC_PACKET = 1, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0x1ccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=7277, (PACKET_SEQUENCE_CONTROL=0xdc6d), PACKET_LENGTH=13, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=1, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=1, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: ENTER_MODE = 41, SOURCE_ID: MISSION_TIMELINE = 110, SPARE=0, CP_LFR_MODE: STANDBY = 0, CP_LFR_ENTER_MODE_TIME=0x000000000000, CRC = 0x65b1
17:19:03.566126, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007cfc0a8
17:19:03.574951, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007d110a8
17:19:03.579086, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007d260a8
17:19:03.585768, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007d3b0a8
17:19:03.588339, TM_LFR_TC_EXE_SUCCESS, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xdc6d
On mesure malheureusement un délai de 15.75s, ce qui est hors tolérance pour les outils automatisés (Python) de mesure de période.
Visiblement, le traitement du TC_LFR_ENTER_MODE provoque cette irrégularité.
Le fonctionnement en régime établi étant ok, je propose un niveau de priorité "Low".
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.0.15
Brique Star-Dundee S/N 46120065.
Soft:1.0.0.1 (variante sur carte finale)
TEST CASE = SVS_0019
Req: SSS-CP-FS-590
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1
Updated by paul leroy almost 11 years ago
- Status changed from New to In Progress
Suite à TC_LFR_ENTER_MODE, LFR aurait dû cesser l'émission des SBM2_CWF_F2.
Je ne vois pas le délais de 15.75 s, il manque la fin de la trace je pense.
Updated by paul leroy over 10 years ago
- Status changed from In Progress to Resolved
Updated by paul leroy over 10 years ago
- Status changed from Resolved to Feedback
- Assignee changed from paul leroy to bruno katra
Updated by bruno katra over 6 years ago
- Status changed from Feedback to Closed
Très vieux et plus observé depuis. On cloture