Project

General

Profile

Activity

From 01/04/2014 to 30/04/2014

30/04/2014

08:07 PM Bug #90 (In Progress): problème d'alignement mémoire dans basic_parameter.c
Nouvelle version de basic_parameter.c (version 1.2). Le pb d'alignement est réglé pour BP1. Au passage, usage de sdti... thomas chust

29/04/2014

02:22 PM Bug #91 (Resolved): nombre de composantes d'une matrice spectrale pour la fonction BP1_set
Nombre de composantes et nombre de fréquences pour les BP 1 et 2 sont maintenant donnés via des paramètres. Cela est ... thomas chust

10/04/2014

04:18 PM Bug #57: TC_LFR_LOAD_NORMAL_PAR renvoie TM_LFR_TC_EXE_NOT_IMPLEMENTED si SY_LFR_N_SWF_L <> default value
Reproduit dans le contexte ci dessous.
+Contexte:+
LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f
C... Gerald Saule
02:25 PM Bug #118: TC_LFR_ENTER_MODE: prise en compte de CP_LFR_ENTER_MODE_TIME
TEST CASE = SVS-0034; SVS-0070/LfrEnterModeTime
 Gerald Saule
10:47 AM Bug #118 (Closed): TC_LFR_ENTER_MODE: prise en compte de CP_LFR_ENTER_MODE_TIME
CP_LFR_ENTER_MODE_TIME n'est actuellement pas prise en compte correctement:
> 10:23:31.251123, TM_LFR_HK, TIME=0x0... Gerald Saule

09/04/2014

04:59 PM Bug #117 (Closed): Gestion de SEQUENCE_CNT dans les TM_LFR_*
Le champ SEQUENCE_CNT des TM correspond au nombre de TM pour chaque couple (PACKET_ID,DESTINATION_ID).
Il y a un pb ... Gerald Saule

03/04/2014

03:02 PM Bug #112: Pb de traitement de TC_LFR_UPDATE_TIME
La contre-manip décrite ci-dessous montre que le pb se reproduit de façon aléatoire.
L'initialisation du traitement ... Gerald Saule
02:00 PM Bug #114 (Closed): TM_LFR_TC_EXE_ERROR inopportun
LFR émet TM_LFR_TC_EXE_ERROR sans justification.
Au démarrage, la commande d'une transition vers STANDBY est rejetée... Gerald Saule

02/04/2014

02:02 PM Bug #113 (Closed): Affectation des champs de TM_LFR_HK en fin de boot du LFR
Les HK de début d'execution sont en
> 11:26:59.425762, TM_LFR_HK, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET ... Gerald Saule
01:45 PM Bug #112 (Closed): Pb de traitement de TC_LFR_UPDATE_TIME
Cette issue est proche de l'issue Bug #111 "Pb de timing dans le traitement de TC_LFR_UPDATE_TIME" (https://hephaisto... Gerald Saule
12:37 PM Bug #111 (Closed): Pb de timing dans le traitement de TC_LFR_UPDATE_TIME
Le changement de temps interne (au LFR) doit se faire sur réception du time code.
Par le code Python, on envoie TC_L... Gerald Saule

01/04/2014

09:47 AM Bug #77 (Resolved): Reset HW met à 0 le bit MSB du temps interne (qui représente la synchronisation avec un "time code")
fsw >= 1.0.0.5
vhdl >= 0.1.9
La fonction de gestion du temps est normalement complètement opérationnelle. Au démarr... paul leroy
09:43 AM Bug #68 (Resolved): Initialisation de l'heure interne du LFR: pb avec le MSB
fsw >= 1.0.0.5
vhdl >= 0.1.9
Au démarrage, le temps est réinitialisé à 0x80000000. LFR attend une synchro valide ... paul leroy
08:48 AM Bug #72 (Resolved): Perte de périodicité sur ultime TM_LFR_SCIENCE_SBM2_CWF_F2
paul leroy
08:19 AM Bug #73 (Resolved): Par défaut, l'envoi de TM_LFR_SCIENCE_NORMAL_CWF_LONG_F3 est privilégié devant TM_LFR_SCIENCE_NORMAL_CWF_F3 (valeur par défaut de SY_LFR_N_CWF_LONG_F3).
Un test avec fsw = 1.0.0.5 en mode NORMAL avec les paramètres par défaut déclenche une émission des paquets TM_LFR_SC... paul leroy
07:36 AM Bug #82 (Resolved): Pas de control sur SY_LFR_N_SWP_P de TC_LFR_LOAD_NORMAL_PAR
La valeur 65528 est le multiple de 8 le plus proche de 65535.
La nécessité d'avoir des multiples de 8 comme périod... paul leroy
07:30 AM Bug #108 (Resolved): Champs TIME et ACQUISITION_TIME différents dans les TM_LFR_SCIENCE_*
fsw >= 1.0.0.5
Les champs TIME et ACQUISITION_TIME sont maintenant identiques dans les paquets SWF et CWF.. paul leroy
 

Also available in: Atom