Bug #584
closed
[QR R3] [RPWSWR-621] : discussions internes sur CWF_F3 ACQ_TIME = 0x0000000
Added by bruno katra almost 9 years ago. Updated almost 8 years ago.
90%
Description
1-
Décider en interne si :
- correction au niveau FSW
- correction au niveau L1 ou L2
2-
Soumettre pour approbation à B. Pontet
3-
RFD? RFW?
Related issues
Updated by bruno katra almost 9 years ago
- Related to Bug #362: CWF_F3 : Champ PA_LFR_ACQUISITION_TIME=0x000000000000 added
Updated by bruno katra almost 9 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 20
Salut !
Je relance la discussion entamée lors de la QR concernant le bug des CWF F3 mal datés (bug redmine #362). L'idée est de statuer sur une solution unanime entre nous et la proposer à Bernard Pontet pour approbation.
Description du problème :
Lorsque l'on passe en mode NORMAL, le premier buffer de 2688 points de CWF à F3 transmis (en 8 paquets de 336 échantillons = 168 s de données) est daté avec un ACQUISITION_TIME à 0x000000000. SEUL le premier buffer est concerné, les buffers suivants sont correctement datés.
Solution proposée :
La solution à mettre en œuvre est je pense unilatéralement reconnue par tous : attendre le 2ème buffer et utiliser son ACQUISITION_TIME pour en déduire un temps artificiel (i.e. non daté par le FPGA) du premier échantillon puis écraser la valeurs 0x000000 par cette valeur déduite.
Mise en œuvre :
Pour ma part, la correction peut intervenir à 3 niveaux :
1 - au niveau FSW : ça a l'avantage de corriger l'erreur en amont et qu'elle n'arrive jamais au sol. Mais cela implique que l'on introduit une datation artificielle dont la traçabilité risque de se perdre dans les années même si cela est décrit dans la documentation de LFR (on imagine mal les utilisateurs des données dans 5 ans aller lire la specif LFR ou le SDD pour trouver cette info...). Autre problème, après réflexion (TBC par Paul) : est-il si facile de garder en cache un buffer entier le temps d'avoir le buffer suivant et d'envoyer du coup 2 salves complètes au bout de 2x168s. Un tel comportement devra être bien décrit dans le SUM.
2 - au niveau segment sol L0 vers L1 : c'est le plus en amont au sol mais cela implique une action du LESIA au niveau DECOM. Le temps serait corrigé et on peut imaginer un caveat ou un warning dans le CDF directement qui avertisse de cette datation à posteriori.
3 - au niveau segment sol L1 vers L2 : c'est un peu tard dans la chaîne mais ce serait fait au niveau LPP (Bruno) puisque nous fournissons le SW L1 vers L2. Idem que précédemment (solution 2), la correction serait tracée directement dans un champ du CDF. Thomas pense aussi que le niveau L1 sera évidemment peu utilisé pour la science donc ce n'est pas critique si la correction n'intervient qu'à partir du L2.
A méditer...
Bon week-end
Bruno
Updated by bruno katra almost 9 years ago
- Status changed from Feedback to In Progress
- Assignee changed from thomas chust to bruno katra
- % Done changed from 20 to 90
Le bug est corrigé (voir #362) : finalement non.
Il reste à commenter le JIRA
Updated by bruno katra almost 9 years ago
Bonjour Philippe.
Nous avions évoqué lors de la QR R3 le bug VHDL qui faisait que le premier paquet paquets CWF_F3 après une transition de mode était mal datés i.e. ACQUISITION_TIME = 0x000000000000.
Il avait été dit que ce paquet devait être redaté artificiellement (à partir de l'info du paquet quivant) et Il avait été décidé que nous devions choisir en interne si nous dations artificiellement ce premier paquet au niveau FSW ou au niveau segment sol (L1 ou L2).
Lors de nouveaux tests préliminaires de validation, il s'avère que lorsque l'on fait un ENTER_MODE avec un temps au lieu de 0 : les paquets sont datés correctement. Il s'avère aussi que Paul a modifié la prise en compte de la TC_LFR_ENTER_MODE pour que si l'argument de temps est 0, LFR bascule dans le mode au prochain TIMECODE reçu. Ceci permet de corriger et de fiabiliser le centrage des SWF (RPWSWR-627 et RPWSWR-628 sur SSS-CP-EQS-350), ce qui était un bug majeur à corriger.
Mais maintenant du coup on se pose la question de notre conformité à SSS-CP-EQS-321 ?
"The equipment flight software shall execute the mode transition immediately, without waiting for
time synchronization, if the time given in parameter of the TC_xxx_ENTER_MODE packet is equal
to 0."
Est-ce acceptable ? Car par ailleurs la SSS-CP-EQS-310 stipule "This time parameter always corresponds to the occurrence of a SpaceWire time code"
Si oui, devons nous faire une RFD?
Merci d'avance de ta réponse.
Cordialement
Bruno
Updated by bruno katra almost 8 years ago
- Status changed from In Progress to Closed
Réponse Plasson 2/02/2016 :
Bonjour Bruno,
Est-ce acceptable ? Car par ailleurs la SSS-CP-EQS-310 stipule "This time parameter always corresponds to the occurrence of a SpaceWire time code"
Si oui, devons nous faire une RFD?- Oui, d'autant plus que TC_LFR_ENTER_MODE avec l'argument de temps à 0 n'est utilisé qu'en mode transparent lors de certains tests (pas utilisé en vol). L'esprit de SSS-CP-EQS-321, c'est de dire que si le paramètre de temps vaut 0, alors il faut quand même faire la transition, sans attendre la date passée en paramètre, car cette date n'est pas utilisable. Vous pouvez écrire une RDF par rapport au mot "immediately". C'est surtout important de documenter cela dans le SUM. *
Cordialement,
Philippe
Merci d'avance de ta réponse.CordialementBruno---------------------
RFD 226 issued for R3updated DP
SUM has been updated with the behaviour description for R3 updated DP