Activity
From 15/01/2016 to 13/02/2016
13/02/2016
-
04:47 PM Support #626 (Closed): Lost TM_LFR_HK in 3.0.0.22
Suite au lancement du test /opt/VALIDATION_R3/test_mode_SBMx_12h.py
On observe la perte d'une TM_LFR_HK au dé...-
12:17 PM Task #624: Long test with SBM1 and SBM2 FSW 3.0.0.22
Le test n'etait pas bon. On a recupéré que des HK.
J'ai gardé les fiichiers 2016_02_12_16_55_23*) (ils se trouvent...
12/02/2016
-
05:09 PM Task #620: 3.0.0.22
- Tests fait. Voir les fichiers. Résults similaires à la 3.0.0.20 (#615). OK
-
10:13 AM Task #620: 3.0.0.22
Les fichiers (2016_02_12_08_23_12_packet*) se trouvent sur pc-instru Weekly Erased/Thomas/run-2016-02-12-3.0.0.22-1...-
08:19 AM Task #620: 3.0.0.22
- Installation du software le 12/02/2016
dans /opt/LFR/LFR-FSW/3.0.0.22
Adaptation des scripts pour utiliser cette ve... -
07:52 AM Task #620 (Closed): 3.0.0.22
- Suite à un problème de numérotation de la 3.0.0.21 (livrée en #619), numérotée par erreur 3.0.0.20, j'ai généré la ré...
-
04:58 PM Task #624 (Closed): Long test with SBM1 and SBM2 FSW 3.0.0.22
Description
le script joué est joint il se nomme test_modes_SBMx_12h.py
1 Les parametres utilisés sont ceux par d...-
04:55 PM Task #618: Long test with SBM1 and SBM2 FSW 3.0.0.20
- Paul,
2.
OK pour que cela soit lié à un cas limite de transition qui tombe mal. Pour autant cela n'explique pas que... -
12:26 PM Task #618: Long test with SBM1 and SBM2 FSW 3.0.0.20
- Pour le point 4, tel Eric et Ramzy à la grande époque "nous n'avons pas d'autre explication".
-
12:22 PM Task #618: Long test with SBM1 and SBM2 FSW 3.0.0.20
- Ok c'est noté pour point 2 et 3, ce sera renseigné dans la datapack.
Pour le point 4, aurais-tu une théorie? -
12:11 PM Task #618: Long test with SBM1 and SBM2 FSW 3.0.0.20
- 2.
Il faudrait consulter un log des paquets pour se faire une idée, notamment voir l'arrivée de la TC de changement ... -
12:04 PM Task #618: Long test with SBM1 and SBM2 FSW 3.0.0.20
- 2.
Il faudrait consulter un log des paquets pour se faire une idée, notamment voir l'arrivée de la TC de changement ... -
11:02 AM Task #618: Long test with SBM1 and SBM2 FSW 3.0.0.20
- Résults de tests dans les fichiers joints:
# SWF: idem que pour #614 (logique de synchro semble maitrisée et amplitu... -
01:39 PM Task #614: 3.0.0.20
- Bonjour à tous.
Nous venons de livrer le FSW 3.0.0.20 via l'issue JIRA dédiée :
https://jira-lesia.obspm.fr/browse/... -
08:40 AM Task #614: 3.0.0.20
- On récupère le paramètre sy_lfr_n_swf_p dans les paquets ou on prend la valeur par défaut (300s) puis j'applique la f...
-
08:25 AM Task #614: 3.0.0.20
- Hello Paul, je suis en train d'analyser le dernier test long en date (#618), je vais a priori vous sortir des résulta...
-
11:53 AM Task #622 (Closed): livraison srec 3.0.0.20 et 3.0.0.22
- Voici les archives contenant les srec. J'ai recompilé le logiciel avec l'option qui va bien pour le DPU.
-
08:36 AM Bug #617 (Closed): Invalider les valeurs de SWF_P < 22s
Bug corrigé en 3.0.0.22
L'envoi pour SY_LFR_N_SWP_P d'une valeur < à 22s genere une TM_LFR_EXE_INCONSISTENT
Uti...-
07:43 AM Task #619: 3.0.0.21
- Version mal numérotée, ne pas utiliser. Je vais générer une 3.0.0.22 à la place.
11/02/2016
-
03:12 PM Bug #617 (Resolved): Invalider les valeurs de SWF_P < 22s
- correction effectuée pour 3.0.0.21
-
02:27 PM Bug #617 (Closed): Invalider les valeurs de SWF_P < 22s
- Suite adaptation de l'algo de synchro des SWF à partir de FSW 3.0.0.15, les valeurs inférieures à 22s doivent être em...
-
03:11 PM Task #619 (Closed): 3.0.0.21
- ...
-
02:58 PM Bug #616 (Closed): Long test in SBM1 and SBM2 modes
-
02:42 PM Task #618 (Closed): Long test with SBM1 and SBM2 FSW 3.0.0.20
- Description
le script joué est joint il se nomme test_mode_SBMx_12h.py
1 Les parametres utilisés sont ceux par dé... -
02:32 PM Bug #600 (Closed): transition SBM1 => SBM2 irrégulière pour les ASM (FSW 3.0.0.15)
- Bug corrigé en 3.0.0.16, validé par Thomas.
-
02:28 PM Task #595 (Closed): 3.0.0.14
- Version intermédiaire avant livraison, non utilisée. Cloture.
-
11:49 AM Task #615: Validation SWF 22s pour 3.0.0.20
- Ah oui, si il y a un redémarrage des snapshots, ça explique le saut.
Au démarrage, on part a priori avec un retard... -
11:29 AM Task #615: Validation SWF 22s pour 3.0.0.20
- J'y suis: en fait le "décrochage" observé correspond exactement au moment ou l'on passe de BURST à NORMAL. Cela renvo...
-
11:42 AM Task #614: 3.0.0.20
- J'ai mis à jour mon dessin (révision 1.2), ce n'était pas assez clair.
# la valeur delta_f2 est utilisée une seule f... -
11:20 AM Task #614: 3.0.0.20
- Super Paul pour toutes ces explications et cela n'est pas de trop! :) Effectivement on avance mais j'ai encore des q...
10/02/2016
-
05:38 PM Task #612 (Closed): Long Test in normal mode
- Ok avec Paul : on cloture
-
02:29 PM Task #612: Long Test in normal mode
- Je confirme que dans des tests avec une période longue entre les snapshots, et pas une valeur basse comme 22s, que j'...
-
05:37 PM Bug #616 (Closed): Long test in SBM1 and SBM2 modes
- Test lancé à 17:15
10 mn NORMAL
puis 6h de SBM1
puis 6h de SBM2
puis 10mn de NORMAL. -
04:52 PM Task #615: Validation SWF 22s pour 3.0.0.20
- J'ai refait un test de mon côté. Sur un temps long, je ne vois pas de saut brutal.
Je joins les observations effec... -
02:45 PM Task #615: Validation SWF 22s pour 3.0.0.20
- Pour l'instant, je ne vois pas d'autre explication qu'un saut dans la dérive qui du coup serait compensé brutalement ...
-
12:42 PM Task #615: Validation SWF 22s pour 3.0.0.20
- Test concluant. Silimaire à 3.0.0.19 (#613).
Cependant une différence concerne la resynchro: on observe à la fin un... -
10:14 AM Task #615 (Stalled): Validation SWF 22s pour 3.0.0.20
Suite à l'installation du soft 3.0.0.20, on relance le test avec les swf à 22s. Ce test etait correct en 3.0.0.19 d...-
02:17 PM Task #614: 3.0.0.20
- On va y arriver! Merci en tout cas pour les nombreux tests et validations effectués. Vous êtes des pros!
Les oscil... -
10:06 AM Task #614: 3.0.0.20
- Tests faits sur les SWF montrent une nette amélioration par rapport au premier test long #612
La logique de resynch... -
08:18 AM Task #614: 3.0.0.20
14h40 de NORMAL mode joués cette nuit. Les parametres utilisés sont ceux par défaut du normal mode. Le test s'est...-
09:33 AM Bug #606: Gestion des erreurs: champ HK_LFR_LAST_ER_RID, HK_LFR_LAST_ER_CODE, HK_LFR_LAST_ER_TIME
L'utilisation du banc de test du LESIA simulateur mk2 pourra nous permet de mieux observer si on perd ou pas une HK...-
09:31 AM Support #607 (In Progress): medium Criticity : How can we do it
Pour valider le champ HK_LFR_DPU_SPW_EARLY_EOP, j'ai utilisé le test
/opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0064...
09/02/2016
-
05:22 PM Task #614: 3.0.0.20
- Lancement du tests long à 17h18 : 14h40 de NORMAL avec TIMEGEN et tous les produis nominaux (SWF à 300s et ASM à 360...
-
05:21 PM Task #614 (In Progress): 3.0.0.20
- Installation du software le 09/02/2016
dans /opt/LFR/LFR-FSW/3.0.0.20 + renommage de l'exe sans l'extension 3-0-0-20... -
05:05 PM Task #614 (Closed): 3.0.0.20
- J'ai trouvé un bug sur la resynchro des snapshots. Je propose de lancer le test NORMAL long sur cette version, j'aime...
-
04:38 PM Task #609: 3.0.0.19
- TC_LOAD_LFR_FBINS_MASK sur 3.0.0.19
fonctionne très bien pour toutes les fréquences de F0, F1 et F2 -
04:29 PM Task #613: Validation SWF 22s
- Résultats en première analyse concluants.
- un trou de 642 s sur les SWF est observé durant le BURST mode (ce qui es... -
09:34 AM Task #613 (Closed): Validation SWF 22s
- Ce test enchaine
- 1800s de Normal mode
- 900s de SBM1
- 900s de SBM2
- 600s de NORMAL
- 600s de BURST
- 600s d... -
04:12 PM Bug #491: Liste des champs contenus dans TM_LFR_HK non renseignés.
cela me va pour c'est toi qui a décidé de mettre ses valeurs et que je sais le vérifier.
-
03:33 PM Bug #491: Liste des champs contenus dans TM_LFR_HK non renseignés.
- OK, je fais la modification dans fsw >= 3.0.0.20
On aura donc dans hk_lfr_vhdl_aa_sm:
bit3 input_fifo_write(2)
bit... -
03:27 PM Task #612 (In Progress): Long Test in normal mode
- Ok. on relance le test long dès livraison 3.0.0.20
-
01:50 PM Task #612: Long Test in normal mode
- Je viens de voir un truc louche dans mon code, qui pourrait avoir une influence avec une période longue entre les sna...
-
11:52 AM Task #612: Long Test in normal mode
- ATTENTION : IL Y AVAIT LE TIMEGEN POUR CE TEST DE PRES DE 15H !!!
-
11:48 AM Task #612: Long Test in normal mode
- Désolé il y a de nouveau un bug de dérive comme avec le FSW 3.0.0.18 (#608). Voir les fichiers joints. Le centrage es...
-
09:25 AM Task #612 (Closed): Long Test in normal mode
14h40 de NORMAL mode joués cette nuit. Les parametres utilisés sont ceux par défaut du normal mode. Le test s'est b...
08/02/2016
-
03:56 PM Bug #491: Liste des champs contenus dans TM_LFR_HK non renseignés.
j'ai donc été vérifié les informations de Paul par rapport au document de Jean-Christophe (
les champs HK_LFR_VH...-
03:33 PM Task #608 (Feedback): 3.0.0.18
Peut etre le fait de generer 2 fichiers au lieu d'un est une piste (utilisation de soc.lfrControlPlugin.Set_logPack...-
11:17 AM Task #609: 3.0.0.19
- SI tu veux retrouver les conditions du bug d'alors il faut refaire avec STANBY mais en plus il faut faire 2 fichiers ...
-
11:02 AM Task #609: 3.0.0.19
Je te propose de lancer le meme test que précédemment mais cette fois sans repasser par le mode Standby:
30mn de N...-
11:01 AM Task #609: 3.0.0.19
- La discontinuité au moment du STANDBY est normale, c'est parce qu'on redémarre la manip, alors on se remet dans le ca...
-
10:54 AM Task #609: 3.0.0.19
- Premier retour d'analyse dans les fichier joints. A priori pas mal du tout. Il y a une discontinuité au milieu, au mo...
-
09:26 AM Task #609: 3.0.0.19
- Installation du software le 06/02/2016
dans /opt/LFR/LFR-FSW/3.0.0.19
Adaptation des scripts pour utiliser cette ve...
05/02/2016
-
07:56 AM Bug #606: Gestion des erreurs: champ HK_LFR_LAST_ER_RID, HK_LFR_LAST_ER_CODE, HK_LFR_LAST_ER_TIME
- Pour la perte du HK, je ne suis pas certain qu'il faille incriminer LFR, ça peut venir de la brique. Enlever le câble...
-
07:47 AM Task #608: 3.0.0.18
- Bon, à suivre, et à vérifier lors des prochains tests.
-
07:44 AM Task #609 (Closed): 3.0.0.19
- the compliance between the incoming timecode and the CTR value contained in the
TC_LFR_UPDATE_TIME telecommand is ch...
04/02/2016
-
04:59 PM Task #608: 3.0.0.18
- Juste le nom de fichier qui était incorrect (le contenu était bon)
-
04:54 PM Task #608: 3.0.0.18
- Voilà le dépouillement. C'est nominal et plutôt très bien! Donc on a eu un problème avec le passge par STANDBY ...
-
04:38 PM Task #608: 3.0.0.18
les fichiers de test 30mn SBM1 + 30mn SBM2 sont disponibles sur pc-instru et dans run-2016-02-04-3.0.0.18.1.1.89/sa...-
03:57 PM Task #608: 3.0.0.18
- les fichiers sont binaires et la decom de Bruno ne les decommute pas.
Je oeux tenter un editeur hexa pour voir.
-
03:52 PM Task #608: 3.0.0.18
- Les erreurs, ça peut arriver. Vous rechargez le soft à chaque début de test ou c'est forcément la même version du log...
-
03:45 PM Task #608: 3.0.0.18
Impossible, nous avons lance LFR-SGSE avant notre test pour vérifier. On est des pros....
Par contre, le context...-
03:36 PM Task #608: 3.0.0.18
- D'après Véro cela est absolument impossible. Il s'agit bien du même FSW 3.0.0.18 mais la différence avec avant est l'...
-
03:28 PM Task #608: 3.0.0.18
- Le premier décalage ne m'inquiète pas plus que ça.
Serait-il possible que le test où il y a une dérive continue n'... -
02:58 PM Task #608: 3.0.0.18
- Je n'ai pas encore bien compris la manip (timecode ou pas, avec ou sans timegen ...) mais voilà mes résultats (voir l...
-
02:27 PM Task #608: 3.0.0.18
- 1 test SBM1+ SBM2 + envoi automatique des timecode et se trouvent sur pc-instru/weekly erased /Thomas/run-2016-02-...
-
02:25 PM Task #608: 3.0.0.18
- J'ai essayé sans timecodes, résultats corrects:
Jeu de données 2016_02_04_13_48_07
1) SBM1 démarré à la date 0x33
... -
12:20 PM Task #608: 3.0.0.18
Le test n'utilise pas l'envoi de timecode.
Faut il que je relance les tests avec les timecodes initialisés?
-
12:16 PM Task #608: 3.0.0.18
- Voici un exemple des données que j'ai obtenues, avec les timecodes mais sans timegen:
Jeu de données considéré: 2016... -
11:28 AM Task #608: 3.0.0.18
- J'ai regardé de mon côté. Je ne vois pas ce défaut en démarrant en SBM1 par exemple et en commutant ensuite vers SBM2...
-
11:05 AM Task #608: 3.0.0.18
- analyse faite:
- test1: 1h NM OK (même plutôt très joli!)
- test2: 30min SBM1 + 30min SBM2 *KO* (pas joli du tout ... -
08:12 AM Task #608: 3.0.0.18
2 tests ont été joués et se trouvent sur pc-instru/weekly erased /Thomas/run-2016-02-03.3.0.0.18-1.1.89
- premie...-
08:56 AM Bug #606 (Feedback): Gestion des erreurs: champ HK_LFR_LAST_ER_RID, HK_LFR_LAST_ER_CODE, HK_LFR_LAST_ER_TIME
- Bug corrigé en 3.0.0.18.
Le script rejoué est /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0064/spw_failure_standby.py
... -
08:19 AM Task #605 (Closed): 3.0.0.17
Cette version ne sera pas utilisée car 3.0.0.18 a été livrée dans la foulée.
03/02/2016
-
04:52 PM Task #608: 3.0.0.18
- répertoire /opt/LFR/LFR-FSW/3.0.0.18 créé et rempli avec le FSW 3.0.0.18
-
04:49 PM Task #608 (Closed): 3.0.0.18
- added spacewire_get_last_error() call to the function spacewire_read_statistics
-
04:51 PM Task #605: 3.0.0.17
- répertoire /opt/LFR/LFR-FSW/3.0.0.17 créé et rempli avec le FSW 3.0.0.17
-
04:08 PM Task #605 (Closed): 3.0.0.17
- snapshot resynchro mise à jour
-
04:43 PM Bug #606: Gestion des erreurs: champ HK_LFR_LAST_ER_RID, HK_LFR_LAST_ER_CODE, HK_LFR_LAST_ER_TIME
- Oups, je viens de regarder mon code. J'ai écrit une fonction pour détecter une modif dans les stats SpaceWire et chan...
-
04:29 PM Bug #606 (Closed): Gestion des erreurs: champ HK_LFR_LAST_ER_RID, HK_LFR_LAST_ER_CODE, HK_LFR_LAST_ER_TIME
J'ai joué le script /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0064/spw_failure_standby.py
Ce test consiste à débra...-
04:40 PM Support #607 (Closed): medium Criticity : How can we do it
- Pour valider les erreurs classées de type medium criticity:
comment fait on?
HK_LFR_DPU_SPW_EARLY_EOP
HK_LFR_DPU... -
03:41 PM Bug #601 (Closed): Computation of HK_LFR_LE_CNT : sometimes erroneous
Le bug est corrigé en version 3.0.0.016.
Le script /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0012/ccsds_time_code_...-
03:21 PM Bug #602 (Closed): Status of LFR WATCHDOG stays DISABLED
- Bug corrigé en 3.0.0.16
Le script /home/validation/SCRIPT/just_hk_survey.py a été joué.
L'analyse des HK permet ... -
01:46 PM Task #603: 3.0.0.16
- *En travaillant sur l'explication de la resynchro, et en faisant des tests en parallèle, j'ai vu un truc bizarre (une...
-
12:52 PM Task #603: 3.0.0.16
- Pour répondre à Thomas : le plan de validation de Véro et moi inclue des tests longs en nominal que nous allons lance...
-
12:49 PM Task #603: 3.0.0.16
- Tests fait sur la synchro:
- test 1 : SBM1 30min + SBM2 30min
- test 2 : NM 60 min
Résultats: pas mal du tout, br... -
10:06 AM Bug #491 (In Progress): Liste des champs contenus dans TM_LFR_HK non renseignés.
- Du coup : non ce n’est pas la peine de modifier l'ICD. J'expliquerai ça dans le SUM. Je reviendrai vers toi pour quel...
-
09:48 AM Bug #491: Liste des champs contenus dans TM_LFR_HK non renseignés.
- On pourrait faire une mise à jour de l'ICD, mais on peut aussi documenter ça dans le user manual. Effectivement, il s...
02/02/2016
-
04:53 PM Bug #584: [QR R3] [RPWSWR-621] : discussions internes sur CWF_F3 ACQ_TIME = 0x0000000
- (!)
Bonjour Philippe.
Nous avions évoqué lors de la QR R3 le bug VHDL qui faisait que le premier paquet paquets CW... -
04:33 PM Task #603: 3.0.0.16
Logiciel installé dans /opt/LFR/LFR-FSW/3.0.0.16
Mise à jour des scripts d'initialisation (Famille des /opt/VALIDA...-
03:55 PM Task #603 (Closed): 3.0.0.16
- *****************************
*** 3.0.0.16 *** 02 FEB 2016
_______________________________________
__ fsw___ Chan... -
04:22 PM Bug #491: Liste des champs contenus dans TM_LFR_HK non renseignés.
- Je pense avoir compris : les champs HK sont codés sur 4 bits donc tu renseignes 2 champs d'un coup avec un unsigned c...
-
04:15 PM Bug #491: Liste des champs contenus dans TM_LFR_HK non renseignés.
- Concernant l'ajout des champs, tu fusionnes 4 champs existants en 2 nouveaux ?
HK_LFR_VHDL_AA et HK_LFR_VHDL_SM de... -
03:59 PM Bug #491: Liste des champs contenus dans TM_LFR_HK non renseignés.
- Commentaires de Philippe Plasson ajoutés en edition du commentaire.
-
03:50 PM Bug #491: Liste des champs contenus dans TM_LFR_HK non renseignés.
- Je propose une modification qui ajoute deux champs dans les HK. Voici le commentaire du commit correspondant des sour...
-
04:20 PM Bug #604: Nominal : TC_LFR_UPDATE_TIME + Time-code does'n t work
- LFR doit recevoir plusieurs timecodes valide avant de commencer à les accepter, ce que fait le DPU puisqu'il n'envoie...
-
04:02 PM Bug #604 (Closed): Nominal : TC_LFR_UPDATE_TIME + Time-code does'n t work
Pour valider le fonctionnement nominal du CTR message emis par le DPU et sans utiliser le timegen, j'ai écrit un sc...-
03:59 PM Support #596: Mise à jour logiciel LFR-SGSE
- J'ai fait la modification. Le bit de spare est à 0 maintenant.
-
12:02 PM Task #597: 3.0.0.15
- Oui, on gardera une acquisition simultanée ASM_F0, ASM_F1, ASM_F2, comme au démarrage.
J'ai un peu amélioré la res... -
11:50 AM Bug #602: Status of LFR WATCHDOG stays DISABLED
Suite à l'implementation du WATCHDOG, le script /opt/VALIDATION_R3/lfrverif/common/RulesClasses/hk_reporting.py e...-
10:50 AM Feature #594: Renseigner les champs HK_LFR_LAST_ER_RID HK_LFR_LAST_ER_CODE HK_LFR_LAST_ER_TIME
- A partir de la révision 3.0.0.16 ces champs sont gérés. Pour les erreurs gérées par le driver SpaceWire, à chaque fab...
01/02/2016
-
03:48 PM Support #596: Mise à jour logiciel LFR-SGSE
Il y a un champ hk_lfr_dpu_spare qui vaut 2 (il est avec le watchdog,..).
Je suppose qu'il correspond au premier c...-
03:38 PM Support #596: Mise à jour logiciel LFR-SGSE
- Dites moi quand le code est figé, je générerai les Packages.
-
03:30 PM Support #596: Mise à jour logiciel LFR-SGSE
- J'ai ajouté plusieurs champs à l'interface, notamment les suivants:
hk_lfr_timecode_erroneous
hk_lfr_timecode_mis... -
03:40 PM Task #597: 3.0.0.15
- paul leroy wrote:
> Effectivement, en creusant et en comparant à des choses que j'ai déjà eues, j'ai trouvé un décal... -
02:38 PM Task #597: 3.0.0.15
- Effectivement, en creusant et en comparant à des choses que j'ai déjà eues, j'ai trouvé un décalage d'une T2. Je fait...
-
08:43 AM Task #597: 3.0.0.15
- Comme promis voici en pièces jointes: fichier de sortie de mon programme en partie plus explicite + figures associées...
-
03:35 PM Bug #560: activer la vérification du cache du Leon3FT
- L'aspect FT est activé par défaut. En tout cas, c'est ce que j'ai constaté sur l'EQM. Se référer à [[Leon3FT_fault_to...
-
03:28 PM Feature #598: Implémentation watchdog
- J'ai modifié le fonctionnement:
Le timer matériel affecté au watchdog a une durée de 10 secondes. Il est réarmé to... -
03:24 PM Bug #602: Status of LFR WATCHDOG stays DISABLED
- J'ai mis à jour la variable sy_lfr_watchdog_enabled dans la version 3.0.0.16.
Mon timer watchdog a une durée de 10... -
02:45 PM Bug #602 (Closed): Status of LFR WATCHDOG stays DISABLED
Le script /home/validation/SCRIPT/just_hk_survey.py permet de vérifier l'environnement stocké dans les TM_LFR_HK et...-
03:02 PM Bug #601: Computation of HK_LFR_LE_CNT : sometimes erroneous
- Good catch comme dirait l'autre. Dans la rev <= 3.0.0.15, j'additionnais les compteurs avant de mettre à jour le cham...
30/01/2016
-
05:53 PM Bug #601 (Closed): Computation of HK_LFR_LE_CNT : sometimes erroneous
Lors de l'execution du script /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0012/ccsds_time_code_format.py
Parfois le ca...
29/01/2016
-
04:43 PM Task #597: 3.0.0.15
- Un petit bémol après quelques réflexions avec Bruno:
* ce que j'ai en fait mesurée explicitement est la variation de... -
04:06 PM Bug #491 (Feedback): Liste des champs contenus dans TM_LFR_HK non renseignés.
- Vu Paul le 28/01/2016, JIRA renseigné après ça + demande de validation à Philippe Plasson :
Bonjour Philippe, nous a... -
12:50 PM Bug #600: transition SBM1 => SBM2 irrégulière pour les ASM (FSW 3.0.0.15)
- Je te joins le fichier log. Sinon il faut regarder (par exemple):
- ligne 445 (pour F0):
dtime(0) = time(1)-tim... -
12:38 PM Bug #600: transition SBM1 => SBM2 irrégulière pour les ASM (FSW 3.0.0.15)
- Je ne m'y retrouve pas dans ton fichier joint. Que dois-je regarder?
Un log des paquets serait plus parlant pour m...
28/01/2016
-
11:01 PM Bug #600 (Closed): transition SBM1 => SBM2 irrégulière pour les ASM (FSW 3.0.0.15)
- Pour les CWF et les SWF la transition est transparente. Pas de décalage observé.
C'était l'un des buts des dernière... -
10:39 PM Task #597: 3.0.0.15
- Bingo ! Comment as-tu fait Paul? Cela tombe d'équerre (à 2-3 fine times près) du début jusqu'à la fin du fichier, exc...
-
01:22 PM Task #597: 3.0.0.15
Installation du 3.0.0.15 sur pc-faust9 dans /opt/LFR/LFR-FSW/3.0.0.15
Les scripts de lancement ont été mis à jou...-
11:05 AM Task #597 (Closed): 3.0.0.15
- principale modification sur la resynchro des snapshots
test effectué avec 22s de période -
03:07 PM Bug #362 (In Progress): CWF_F3 : Champ PA_LFR_ACQUISITION_TIME=0x000000000000
- REOUVERTURE :
Il s'agit bien d'un bug VHDL comme avait dit JC MAIS il se trouve que si l'on commute à une DUE_DATE (... -
10:38 AM Bug #362 (Closed): CWF_F3 : Champ PA_LFR_ACQUISITION_TIME=0x000000000000
- Le retour des CWF_F3 bien daté a été constaté par plusieurs confs de test (EM2, Mini-lfr, avec et sans timegen).
Il ... -
03:00 PM Bug #487 (Closed): TC_LFR_LOAD_FBINS_MASK semble ne pas avoir d'effet sur les produits BP2
- CTC610/611/612 corrigés pour faire varier le masque dans le bon sens .
Analyses des résultats pour CTC-610(F0), CTC-... -
02:51 PM Support #181 (In Progress): Impossibilité de provoquer un TM_LFR_EXE_ERROR
- Voir procédure suite QR R3 :
https://jira-lesia.obspm.fr/browse/RPWSWR-448?jql=text%20~%20%22EXE_ERROR%22
Ca basc... -
02:03 PM Feature #598 (In Progress): Implémentation watchdog
-
02:02 PM Feature #598: Implémentation watchdog
Bonjour Bruno,
Le 28 janvier 2016 à 08:56, Bruno Katra <bruno.katra@lpp.polytechnique.fr> a écrit :
Bonjour ...-
02:02 PM Feature #598: Implémentation watchdog
- Ben effectivement, j'ai implémenté quelque-chose, mais je ne vois toujours pas bien l'utilité.
La tâche LOAD arme ... -
02:00 PM Feature #598 (Closed): Implémentation watchdog
- Faire un WD "à la tds" suite à QR R3
-
01:08 PM Bug #591 (Closed): HK_LFR_TIME_NOT_SYNCHRO stays to 1
En version 3.0.0.14, après la sequence de boot, Paul met le HK_LFR_TIME_NOT_SYNCHRO à ZERO.
le script utilisé es...-
11:54 AM Bug #558: [QR R3] [RPWMEB-515] - TM_LFR_TC_EXE_INCONSISTENT au lieu de TM_LFR_TC_EXE_NOT_EXECUTABLE attendu
Bug (qui n'en est pas un) est corrigé en 3.0.0.14.
Le script rejoué est /opt/VALIDATION_R3/lfrverif/LFR-SVS/SVS-00...-
11:12 AM Bug #558 (In Progress): [QR R3] [RPWMEB-515] - TM_LFR_TC_EXE_INCONSISTENT au lieu de TM_LFR_TC_EXE_NOT_EXECUTABLE attendu
- Constaté OK par Véronique.
A cloturer après maj SRS. -
11:26 AM Bug #62: Mise à jour ICD
- Les valeurs ASM sont marquée comme integer dans l'iCD alors que ce sont des floats IEEE754
==> demandé dans https://... -
11:15 AM Bug #450 (In Progress): SSS-CP-EQS-526 non conforme par rapport à ICD >= 3.3
- Traité au niveau CNES par NC208 et accepté par le projet (QR R3).
A clôturer après datapack QR R3 updated -
10:39 AM Bug #584 (In Progress): [QR R3] [RPWSWR-621] : discussions internes sur CWF_F3 ACQ_TIME = 0x0000000
- -Le bug est corrigé- (voir #362) : finalement non.
Il reste à commenter le JIRA
27/01/2016
-
04:21 PM Bug #581: [QR R3] [RPWSWR-625] : document de caractérisation à fournir au CNES
- Les documents joints au mail ci-après du 22/01/2016 ont été présenté au ISWG à Madrid le 25-26 janvier 2016
-------... -
04:04 PM Feature #588 (In Progress): traitement des champs TIMECODE et TIME dans les paquets HK
-
08:48 AM Support #596: Mise à jour logiciel LFR-SGSE
Consulter le point feature #588
-
08:47 AM Support #596 (Stalled): Mise à jour logiciel LFR-SGSE
Il faudrait mettre à jour le logiciel LFR-SGSE pour visualiser sur l'interface HK les nouveaux champs
implémentés....-
08:39 AM Task #595: 3.0.0.14
Voici donc le nouvel environnement de test
FSW 3.0.0.14
VHDL 1.1.89
EM sans Timegen
SocExplorerEngine.getSocExp...-
08:38 AM Task #595 (In Progress): 3.0.0.14
Installation du 3.0.0.14 sur pc-faut9 dans /opt/LFR/LFR-FSW/3.0.0.14.
Les scripts de lancement ont été mis à jour....
26/01/2016
-
11:56 PM Task #590: livraison version 3.0.0.13
- Dans la même veine pour les CWF, test fait sur la régularité des paquets. Résultat dans le fichier joint. Même conclu...
-
09:57 AM Task #590: livraison version 3.0.0.13
- J'ai trouvé le bug. Finalement, je suis revenu à une solution ou je resynchronise en utilisant 1 snapshot sur 2:
1) ... -
12:18 AM Task #590: livraison version 3.0.0.13
- J'ai fait des tests (régularité de la période de 22 s + centrage des SWF) sur les données fournies par véro (voir s...
-
04:13 PM Task #595 (Closed): 3.0.0.14
- Livraison de la version 3.0.0.14
-
03:58 PM Bug #362: CWF_F3 : Champ PA_LFR_ACQUISITION_TIME=0x000000000000
- Je ne m'explique pas le phénomène pour l'instant. J'ai changé la gestion des interruptions pour m'adapter à la nouvel...
-
02:58 PM Bug #362: CWF_F3 : Champ PA_LFR_ACQUISITION_TIME=0x000000000000
Suite à l'installation du LFR-SFW version 3.0.0.13, l'analyse montre que le timing des CWF_F3 en normal mode est co...-
03:27 PM Bug #558: [QR R3] [RPWMEB-515] - TM_LFR_TC_EXE_INCONSISTENT au lieu de TM_LFR_TC_EXE_NOT_EXECUTABLE attendu
- fsw >= 3.0.0.14
J'ai fait la modification, je renvoie maintenant TM_LFR_TC_EXE_NOT_EXECUTABLE si la date est erronée. -
03:21 PM Bug #238: Wrong behavior after SY_xxx_DPU_CONNECT_ATTEMPT unsuccessful attempts of connection with the DPU
- corrigé dans fsw >= 3.0.0.14
J'ai repéré le bug. Les HK n'était pas à jour et la variable locale lfrCurrentMode non ... -
03:03 PM Feature #594 (Closed): Renseigner les champs HK_LFR_LAST_ER_RID HK_LFR_LAST_ER_CODE HK_LFR_LAST_ER_TIME
Suite à la gestion des erreurs liées au timing cf (Task #590 et Feature #588) , il faudrait également renseigner l...-
09:29 AM Feature #593 (In Progress): adapter tm_lfr_period.py au fonctionnement des modes
Le normal mode ne s'interrompant plus quand on commute vers sbm1 et sbm2, il faut modifier
la fonction tm_lfr_per...-
09:08 AM Bug #592 (Closed): tm_period.py doesn't perform SBM1_BP2_F0
Le bug a été identifé.
Le fichier en cause est /opt/VALIDATION_R3/lfrverif/common/RulesClasses/tm_lfr_period.py.
...-
09:02 AM Bug #592 (Closed): tm_period.py doesn't perform SBM1_BP2_F0
Le script verif_fields.py utilise la fonction tm_period.py pour vérifier les timing des TM_LFR_SCIENCE.
Cette fonc...-
08:20 AM Bug #591: HK_LFR_TIME_NOT_SYNCHRO stays to 1
- C'est un compteur du nombre de transition synchronisé (bit 31 à 0) vers désynchronisé (bit 31 à 1).
On commence dé... -
08:08 AM Bug #591: HK_LFR_TIME_NOT_SYNCHRO stays to 1
Je suis d'accord avec cette analyse mais cela ne me dit pas si tu le consideres comme un compteur,c'est à dire qu'à...-
07:16 AM Bug #591: HK_LFR_TIME_NOT_SYNCHRO stays to 1
- Pour moi, le champ reflète la perte de la synchro, c'est à dire le passage de 0 à 1 du bit 31 du coarse_time. A mon a...
25/01/2016
-
04:43 PM Bug #591: HK_LFR_TIME_NOT_SYNCHRO stays to 1
Je viens de me rendre compte que le champ HK_LFR_TIME_NOT_SYNCHRO est un compteur et non un cchamp de statut. (0= S...-
04:18 PM Bug #591 (Closed): HK_LFR_TIME_NOT_SYNCHRO stays to 1
Après la sequence de boot, LFR n'est pas synchronisé, sur les premiers blocs de TM_LFR_HK on observe donc
- le bit...-
04:02 PM Task #559: Garantir que la réception est désactive sur l'APBUART.
- J'ai enlevé la fonction qui ne servait pas.
De mon côté, j'initialise avec le soft le registre de contrôle de l'AP... -
03:47 PM Task #590: livraison version 3.0.0.13
- C'est pas forcément sain qu'une désynchro soit repérée juste après le boot puisque c'est normal de commencer désynchr...
-
02:57 PM Task #590: livraison version 3.0.0.13
Installation de la version 3.0.0.13 sur pc-faust9.
Voici donc le nouvel environnement de test
FSW 3.0.0.13
VHD...-
09:01 AM Task #590: livraison version 3.0.0.13
- Normalement oui.
-
03:33 PM Bug #560: activer la vérification du cache du Leon3FT
- Plusieurs choses à faire sur la carte EQM:
Lancer le soft en développement (>= 3.0.0.14) et vérifier que le Leon3FT ...
23/01/2016
-
07:40 PM Task #590: livraison version 3.0.0.13
- Paul, une question bête. Cela marche t-il aussi pour les transitions suivantes:
SBM1 => SBM2 ?
SBM2 => SBM1 ?
22/01/2016
-
05:24 PM Task #590 (Closed): livraison version 3.0.0.13
- Voici une version qui évoluera mais sur laquelle vous pouvez travailler.
Ce qui marche: commutation des modes selon ... -
05:03 PM Feature #587: Mise en conformité de timegen avec SSS-CP-FS-370 (spw timecode value et CTR coarse time)
- Il n'y a pas à mettre en conformité timegen, il ne gère pas les timecodes. Pour avoir des timecode conformes au TC_LF...
-
05:00 PM Support #561: Modifer le masque utilisé pour lire le time-code valide
- La modification a été faite dans fsw 3.0.0.13. Le pasque 0x3f est utilisé partout.
-
04:59 PM Feature #588: traitement des champs TIMECODE et TIME dans les paquets HK
- J'ai travaillé sur la gestion des champs suivants:
hk_lfr_timecode_erroneous
hk_lfr_timecode_missing
hk_lfr_timeco...
21/01/2016
-
01:56 PM Support #589 (Closed): TC_LFR_LOAD_FBINS_MASK
- *A METTRE DANS LE SUM*
Voici quelles précisions concernant l'utilisation de la commande
TC_LFR_LOAD_FBINS_MASK
... -
01:23 PM Bug #186 (Closed): Probleme timing sur les Basic Parameters
-
10:20 AM Feature #588 (Closed): traitement des champs TIMECODE et TIME dans les paquets HK
- Expliquer comment sont gérer les champs suivants dans les paquets HK:
SOURCE_DATA/PARAMETERS/ERRORS_COUNTERS/TIMEC... -
10:16 AM Feature #587 (Closed): Mise en conformité de timegen avec SSS-CP-FS-370 (spw timecode value et CTR coarse time)
- Rappel d'une partie de l'exigence SSS-CP-FS-370:
The SpaceWire time code contains the least significant bits of th...
20/01/2016
-
03:06 PM Support #561: Modifer le masque utilisé pour lire le time-code valide
Envoi d'un mail à Philippe :
Bonjour,
Nous nous interrogeons avec Paul sur le format du time-code.
Le time-cod...-
11:34 AM Support #561: Modifer le masque utilisé pour lire le time-code valide
- Est-on sûr que les bits de contrôle ne doivent pas être conservés? Ils font peut-être partie du timecode, qui serait ...
-
11:31 AM Bug #553: NON CONFORMITE SSS-CP-EQS-326
- Modification de la commutation des modes effectuée pour la révision 3.0.0.13.
-
11:29 AM Bug #548: erreurs d'enregistrement des SWF_F1 et SWF_F0 à 16 s en SBM2 (doublons + temps)
- J'ai identifié l'origine du problème, ça vient du fait qu'il faut attendre d'avoir suffisament de buffers de 2688 poi...
-
09:58 AM Bug #554: Problème datation waveform par rapport à SSS-CP-EQS-340
- Comment avez-vous mesurés ces 800us? Vous pouvez me mettre un plot et me décrire le test?
-
09:54 AM Bug #245: synchronisation des snapshots
- J'ai fait une modification dans la version 3.0.0.13 au niveau de la fonction de synchronisation des snapshots. La cor...
19/01/2016
-
08:25 AM Bug #487: TC_LFR_LOAD_FBINS_MASK semble ne pas avoir d'effet sur les produits BP2
- La représentation est en MSB first. C'est ce qui est utilisé pour tous les champs contenant plusieurs octets dans les...
18/01/2016
-
04:52 PM Task #557 (Closed): Révision 3.0.0.12
-
02:29 PM Task #557 (In Progress): Révision 3.0.0.12
- Test grossier rejoué : on masque toutes les frequences et on génère 1632 H, l'effet se voit maintenant dans les BP2 ...
-
12:45 PM Task #557: Révision 3.0.0.12
- Je remets la version 3.0.0.12, recompilée aujourd'hui à partir des sources taggées 3.0.0.12. J'avais peut-être fait u...
-
04:52 PM Bug #487 (Feedback): TC_LFR_LOAD_FBINS_MASK semble ne pas avoir d'effet sur les produits BP2
- Salut Paul !
Avec la 3.0.0.12 les FBINS_MASK fonctionnent.
Cependant, après de nombreux tâtonnements il s'avère que... -
04:30 PM Bug #487: TC_LFR_LOAD_FBINS_MASK semble ne pas avoir d'effet sur les produits BP2
- Test grossier rejoué : on masque toutes les frequences et on génère 1632 H, l'effet se voit maintenant dans les BP2 :...
Also available in: Atom