INSTRU: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012016-02-23T13:56:33ZRedmine
Redmine LFR-FSW - Support #634 (Closed): SEction HK_LFR_STATUS_WORD in TM_LFR_HKhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/6342016-02-23T13:56:33ZVeronique bouzid
<p>Peux-tu me confirmer pour chacun des champs ci-dessous* si tu les remplis et avec quelles valeurs.*</p>
<p>HK_LFR_DPU_SPW_LINK_STATE : <br />je n ai observé que la valeur RUN.</p>
<p>HK_LFR_RESET_CAUSE: <br />je n ai observé que la valeur POWER_ON d'ailleurs je n ai trouvé qu'un seul appel à la fonction set_hk_lfr_reset_cause</p>
<p>Contexte du test<br />---------------------<br />FSW 3.0.0.22<br />VHDL 1.1.89<br />Timegen 0.0.0.1<br />EM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />StarDundee</p> LFR-FSW - Support #627 (Closed): Commutation immediatehttps://hephaistos.lpp.polytechnique.fr/redmine/issues/6272016-02-14T09:10:52ZVeronique bouzid
<p>_<br />Sur le test joué en 3.0.0.22, je regarde la commutation<br />NORMAL vers SBM1 car plus facile à valider vu que les produits CWF_F1 sont tout de suite disponibles.</p>
<p>La commutation demandée est immediate, ce qui signifie qu'elle sera effective sur le tick-out d'apres = la seconde suivante.<br />2016 2 13 11:58:53:343 TM_LFR_HK time = 0x 1e51d6fc 6174<br />2016 2 13 11:58:53:512 TM_LFR_TC_EXE_SUCCESS time =* 0x 1e51d6fc 8cf1*<br />2016 2 13 11:58:53:770 TM_LFR_SCIENCE_SBM1_CWF_F1 time =* 0x 1e51d6fc 259d*</p>
<p>Je m'attends donc à voir arriver un produit CWF_F1 proche de 0x 1e51d6fd voire meme au mieux 1e51d6fc eaff (ffff-1500) mais comme on doit avoir 8 buffers, le calcul<br />doit etre FFFF-A800=557F.<br />Ce n'est pas le cas, on a l'impression même que la commutation a été immédiate.</p>
<p>1er groupe<br />2016 2 13 11:58:53:770 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc 259d<br />2016 2 13 11:58:53:782 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc 3a9d<br />2016 2 13 11:58:53:782 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc 4f9d<br />2016 2 13 11:58:53:794 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc 649d<br />2016 2 13 11:58:53:794 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc 799d<br />2016 2 13 11:58:53:804 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc 8e9d<br />2016 2 13 11:58:53:808 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc a39d<br />2016 2 13 11:58:53:808 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc b89d</p>
<p>2eme groupe (A800 fine-time plus loin)<br />2016 2 13 11:58:54:426 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc cd9d /A800) soit 43008 fine-time<br />2016 2 13 11:58:54:438 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc e29d<br />2016 2 13 11:58:54:438 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc f79d<br />2016 2 13 11:58:54:450 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fd c9d -> la on a franchi la seconde / commutation demandée<br />2016 2 13 11:58:54:450 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fd 219d<br />2016 2 13 11:58:54:454 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fd 369d<br />2016 2 13 11:58:54:467 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fd 4b9d<br />2016 2 13 11:58:54:467 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fd 609d<br />2016 2 13 11:58:54:503 TM_LFR_SCIENCE_SBM1_BP1_F0 time = 0x 1e51d6fd 3da1<br />2016 2 13 11:58:54:735 TM_LFR_SCIENCE_SBM1_BP1_F0 time = 0x 1e51d6fd 7da1</p>
<p>donc on aurait du commencer à voir seulement les produits du 2eme groupe</p>
<p>--> EST CE QUE MON ANALYSE EST CORRECTE?</p>
<p>Autre explication:<br />Tu prends le premier groupe car tu as deja le buffer qui est disponible et tu estimes compatible avec le temps de commutation.</p>
<p>Le second buffer arrive trop loin de la seconde soit 0x 1e51d6fc cd9d + A800 = 0x 1e51d6fd bda1.</p>
<p>QUELLE EST LA BONNE ANALYSE?</p>
<p>Il faut vraiment documenter cette partie pour renseigner la SRS et eventuellement le SUM._</p> LFR-FSW - Support #626 (Closed): Lost TM_LFR_HK in 3.0.0.22 https://hephaistos.lpp.polytechnique.fr/redmine/issues/6262016-02-13T15:47:08ZVeronique bouzid
<p>Suite au lancement du test /opt/VALIDATION_R3/test_mode_SBMx_12h.py</p>
<p>On observe la perte d'une TM_LFR_HK au début du test .<br />2016 2 13 11:48:53:509 TM_LFR_TC_EXE_NOT_EXECUTABLE time = 0x 1e51d4a2 870c<br />2016 2 13 11:48:53:513 TM_LFR_TC_EXE_SUCCESS time = 0x 1e51d4a2 8d55<br />2016 2 13 11:48:54:343 TM_LFR_HK time = <strong>0x 1e51d4a3 628b</strong><br />2016 2 13 11:48:55:343 TM_LFR_HK time = <strong>0x 1e51d4a6 628b</strong><br />2016 2 13 11:48:56:343 TM_LFR_HK time = 0x 1e51d4a7 628b<br />2016 2 13 11:48:57:343 TM_LFR_HK time = 0x 1e51d4a8 628a</p>
<p>Vu également sur la version 3.0.0.20.<br />3.0.0.20 avec timegen (2016_02_10_17_15_12_packet_log.data)<br />2016 2 10 17:15:12:504 TM_LFR_TC_EXE_NOT_EXECUTABLE time = 0x 1e4e2c9e f521<br />2016 2 10 17:15:12:507 TM_LFR_TC_EXE_SUCCESS time = 0x 1e4e2c9e f52e<br />2016 2 10 17:15:12:515 TM_LFR_TC_EXE_SUCCESS time = 0x 1e4e2c9e f53d<br />2016 2 10 17:15:12:539 TM_LFR_TC_EXE_SUCCESS time = 0x 1e4e2c9e fc14<br />2016 2 10 17:15:12:573 TM_LFR_HK time = 0x 1e4e2c9f 6b0<br />2016 2 10 17:15:13:554 TM_LFR_HK <strong>time = 0x 1e4e2ca1 1ee</strong><br />2016 2 10 17:15:14:554 TM_LFR_HK time = 0x 1e4e2ca2 1ee<br />2016 2 10 17:15:15:554 TM_LFR_HK time = 0x 1e4e2ca3 1ed<br />2016 2 10 17:15:16:554 TM_LFR_HK time = 0x 1e4e2ca4 1ed</p>
<p>Si on avait la decommutation des HK, on pourrait voir si le SEQUENCE_CNT du packet est coherent avec une perte de paquet.</p>
<p>J'ai analysé les autres tests et c'est la deuxieme ois que je le vois mais on a peu de tests avec timegen pour comparer.</p>
<p>Contexte du test<br />---------------------<br />FSW 3.0.0.22<br />VHDL 1.1.89<br />EM AVEC Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />StarDundee</p> LFR-FSW - Support #607 (Closed): medium Criticity : How can we do ithttps://hephaistos.lpp.polytechnique.fr/redmine/issues/6072016-02-03T15:40:56ZVeronique bouzid
<p>Pour valider les erreurs classées de type medium criticity:<br />comment fait on?</p>
<p>HK_LFR_DPU_SPW_EARLY_EOP<br />HK_LFR_DPU_SPW_INVALID_ADDR<br />HK_LFR_DPU_SPW_EEP<br />HK_LFR_DPU_SPW_RX_TOO_BIG<br />HK_LFR_BUFFER_DPU_TC_FIFO<br />HK_LFR_BUFFER_DPU_TM_FIFO<br />HK_LFR_AHB_UNCORRECTABLE</p> LFR-FSW - Support #596 (Stalled): Mise à jour logiciel LFR-SGSEhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/5962016-01-27T07:47:27ZVeronique bouzid
<p>Il faudrait mettre à jour le logiciel LFR-SGSE pour visualiser sur l'interface HK les nouveaux champs<br />implémentés.</p> LFR-FSW - Support #589 (Closed): TC_LFR_LOAD_FBINS_MASK https://hephaistos.lpp.polytechnique.fr/redmine/issues/5892016-01-21T12:56:32ZVeronique bouzid
<p><strong>A METTRE DANS LE SUM</strong></p>
<p>Voici quelles précisions concernant l'utilisation de la commande<br />TC_LFR_LOAD_FBINS_MASK</p>
<p>On va reprendre la notation de Paul:</p>
<p>La représentation est en MSB first. C'est ce qui est utilisé pour tous les champs contenant plusieurs octets dans les paquets TC/TM (paragraphe 1.2 "Bit Numbering Convention" de l'ICD). Je suis d'accord que pour éviter tout risque de confusion, il faudrait documenter ça proprement quelquepart, éventuellement avec un exemple. Je propose d'ajouter une exigence dans la SRS qui spécifie la convention et d'y associer un test, que tu as déjà sous le coude ou presque. Ca n'exclut pas ta proposition sur le SUM bien entendu.</p>
<p>J'ai vérifié dans l'ICD et il n'y a pas de détail sur la signification des champs FBINS_MASK donc c'est à nous de fixer les choses.</p>
<p>Dans le paquet on a [word1 word2 word3 word4] = [word1_byte3 ... word4_byte0] = [word1_bit31_fbin127 ... word4_bit0_fbin0]</p>
<p>word1 = byte3 byte2 byte1 byte0<br />word2 = byte3 byte2 byte1 byte0<br />word3 = byte3 byte2 byte1 byte0<br />word4 = byte3 byte2 byte1 byte0</p>
<p>byte3 = bit31 ... bit24<br />byte2 = bit23 ... bit16<br />byte1 = bit15 ... bit8<br />byte0 = bit7 ... bit0</p>
<p>Le word4_byte_0_bit0 correspond à la plus petite frequence (voir tableau ci-dessous).</p>
<p>Frequence word4_byte_0_bit0<br />F0 96<br />F1 16<br />F2 1</p>
<p>La fréquence zero n'est pas utilisée. Cette information est extraite du document RPW-MEB-LFR-00003</p>
<p>*REQ-RPW-LFR-2407 Among 128 available frequency bins (f=0 is not considered) for each ASM, only a range depending on the frequency channel will be transmitted to ground and used for the computation of the Basic Parameters:</p>
<p>· ASM_f0[17:104], i.e. 88 bins</p>
<p>· ASM_f1[6:109], i.e. 104 bins</p>
<p>· ASM_f2[7:102], i.e. 96 bins*</p>
<p>F0<br />La premiere bin est à 96 hz<br />Delta à f0 = 96hz<br />F0: [17,104] <br /> freq = [1632., 1728., 1824., 1920., 2016., 2112., 2208., 2304., \<br /> 2400., 2496., 2592., 2688., 2784., 2880., 2976., 3072., \<br /> 3168., 3264., 3360., 3456., 3552., 3648., 3744., 3840., \<br /> 3936., 4032., 4128., 4224., 4320., 4416., 4512., 4608., \<br /> 4704., 4800., 4896., 4992., 5088., 5184., 5280., 5376., \<br /> 5472., 5568., 5664., 5760., 5856., 5952., 6048., 6144., \<br /> 6240., 6336., 6432., 6528., 6624., 6720., 6816., 6912., \<br /> 7008., 7104., 7200., 7296., 7392., 7488., 7584., 7680., \<br /> 7776., 7872., 7968., 8064., 8160., 8256., 8352., 8448., \<br /> 8544., 8640., 8736., 8832., 8928., 9024., 9120., 9216., \<br /> 9312., 9408., 9504., 9600., 9696., 9792., 9888., 9984]</p>
<p>F1<br />La premiere bin est à 16hz<br />Delta à f1 = 16<br />fo = []<br /> freq = [96., 112., 128., 144., 160., 176., 192., 208., \<br /> 224., 240., 256., 272., 288., 304., 320., 336., \<br /> 352., 368., 384., 400., 416., 432., 448., 464., \<br /> 480., 496., 512., 528., 544., 560., 576., 592., \<br /> 608., 624., 640., 656., 672., 688., 704., 720., \<br /> 736., 752., 768., 784., 800., 816., 832., 848., \<br /> 864., 880., 896., 912., 928., 944., 960., 976., \<br /> 992., 1008., 1024., 1040., 1056., 1072., 1088., 1104., \<br /> 1120., 1136., 1152., 1168., 1184., 1200., 1216., 1232., \<br /> 1248., 1264., 1280., 1296., 1312., 1328., 1344., 1360., \<br /> 1376., 1392., 1408., 1424., 1440., 1456., 1472., 1488., \<br /> 1504., 1520., 1536., 1552., 1568., 1584., 1600., 1616., \<br /> 1632., 1648., 1664., 1680., 1696., 1712., 1728., 1744.]</p>
<p>F2<br />La premiere bin est à 1hz<br />Delta à f2 = 1<br /> freq = [7., 8., 9., 10., 11., 12., 13., 14., \<br /> 15., 16., 17., 18., 19., 20., 21., 22., \<br /> 23., 24., 25., 26., 27., 28., 29., 30., \<br /> 31., 32., 33., 34., 35., 36., 37., 38., \<br /> 39., 40., 41., 42., 43., 44., 45., 46., \<br /> 47., 48., 49., 50., 51., 52., 53., 54., \<br /> 55., 56., 57., 58., 59., 60., 61., 62., \<br /> 63., 64., 65., 66., 67., 68., 69., 70., \<br /> 71., 72., 73., 74., 75., 76., 77., 78., \<br /> 79., 80., 81., 82., 83., 84., 85., 86., \<br /> 87., 88., 89., 90., 91., 92., 93., 94., \<br /> 95., 96., 97., 98., 99., 100., 101., 102.]</p>
<p><strong>Exemple</strong><br />Pour masquer la fréquence 1632Hz, on va calculer le bit à positionner<br />1632/96 = 17 --> bit16<br />Il faudra donc positionner <strong>le bit sy_lfr_fbins_f0_word4_byte2_bit16 à 0</strong></p>
<p>Pour masquer la fréquence 112hz on calcule<br />112/16 = 7 --> bit6<br />IL faudra donc positionner <strong>le bit sy_lfr_fbins_f1_word4_byte0_bit6 à 0</strong></p> LFR-FSW - Support #561 (Closed): Modifer le masque utilisé pour lire le time-code validehttps://hephaistos.lpp.polytechnique.fr/redmine/issues/5612015-11-04T07:07:30ZVeronique bouzid
<p>Fichier fsw_spacewire.c</p>
<p>Dans la fonction timecode_irq_handler( )<br />Le masque utilisé pour recuperer le time-code valide est 0xff.<br />Hors le time-code comprend 2 bits de controle (les 2 bits de poids forts) et 6 bits pour la valeur.</p>
<p>Conclusion si on veut etre conforme, il faut utiliser le masque $3f.</p> LFR-FSW - Support #545 (Closed): Send TIMECODE without TC_LFR_UPDATE_TIME after SYNCHRONISATIONhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/5452015-10-20T12:33:29ZVeronique bouzid
<p>Voici le scenario effectué dans le test SVS-0012<br />0- Reset de LFR<br />1- Synchronisation de LFR sur reception d'une TC_LFR_UPDATE_TIME + time code compatible (6bits of least bytes of coarse time<br />2- Send during 60s a time code valid</p>
<p>--> Ce que l on observe<br />14:00:30.509906, TM_LFR_HK, TIME=0x8000000431ad, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_TIME_TIMECODE_CTR=0<br />14:00:31.461884, TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x5447c6010000<br />14:00:31.509805, TM_LFR_HK, TIME=0x8000000531ad, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_TIME_TIMECODE_CTR=0<br />14:00:32.509786, TM_LFR_HK, TIME=0x5447c601bd68, <strong>HK_LFR_DPU_SPW_TICK_OUT_CNT=1, HK_LFR_DPU_SPW_LAST_TIMC=1</strong>, HK_LFR_TIME_TIMECODE_CTR=0<br />14:00:33.509884, TM_LFR_HK, TIME=0x5447c602ba29, <strong>HK_LFR_DPU_SPW_TICK_OUT_CNT=2, HK_LFR_DPU_SPW_LAST_TIMC=2, HK_LFR_TIME_TIMECODE_CTR=1</strong></p>
<p>Cette derniere ligne correspond à l'envoi de time-code sans la TC_LFR_UPDATE_TIME.<br />On voit que le soft a positionné HK_LFR_TIME_TIMECODE_CTR à 1 car le temps demandé(CP_RPW_TIME) dans TC_LFR_UPDATE_TIME = 0x5447c6010000<br />ne correspond pas au time-code = 2.</p>
<p>Il faut donc documenter ce point concernant le compteur HK_LFR_TIME_TIMECODE_CTR. Paul utilise le registre coarse_time_load<br />qui contient la valeur du CP_RPW_TIME de la TC_LFR_UPDATE_TIME.</p> LFR-FSW - Support #537 (Closed): requirement SSS-CP-EQS-522 et SSS-CP-EQS-523https://hephaistos.lpp.polytechnique.fr/redmine/issues/5372015-10-10T08:50:23ZVeronique bouzid
<p>Hello,<br />Me confirmes-tu que ces 2 requirements qui concernent la calibration sont des tests Design??<br />SSS-CP-EQS-522<br />LFR calibration function<br />Upon reception of a TC_LFR_ENABLE_CALIBRATION, the LFR flight software shall enable the<br />LFR calibration function (generation of the calibration signal for the SCM).</p>
<p>et<br />SSS-CP-EQS-523<br />LFR calibration function<br />Upon reception of a TC_LFR_DISABLE_CALIBRATION, the LFR flight software shall disable the<br />LFR calibration function (generation of the calibration signal for the SCM).</p>
<p>Le troisieme requirement est un test de validation décrit dans SVS-0053<br />SSS-CP-EQS-524</p>
<p>LFR calibration function<br />The LFR flight software shall report in its periodic HK packet (TM_LFR_HK) the enable / disable<br />status of the calibration function.</p> LFR-FSW - Support #494 (Feedback): Gestion timecode https://hephaistos.lpp.polytechnique.fr/redmine/issues/4942015-09-11T10:33:03ZVeronique bouzid
<p>J'ai travaillé sur la gestion manuelle de l'envoi de timecode.<br />Pour cela on utilise la fonction SpwPlugin0.StarDundeeSendOneTimecode. Parfois, il faut envoyer 2 timecodes de suite pour que la commande<br />TC_LFR_UPDATE_TIME soit prise en compte, parfois un seul suffit. L'effet de bord est que si les 2 timecodes sont pris en compte, le temps interne de LFR est positionné au temps contenu<br />dans la TC_LFR_UPDATE_TIME + 1s. Donc cela n'etait pas concluant.<br />En effet, la TC_LFR_UPDATE_TIME se traduit par l'ecriture du temps dans le registre COARSE TIME LOAD et l'arrivée du timecode va ecrire ce registre dans le registre COARSE TIME. La reception du 2eme<br />timecode lui, incrementera de 1 ce temps.</p>
<p>--> Conclusion ce n'est pas ce que l'on veut.</p>
<p>En fait je me suis rendue compte que si je resette la carte LFR, je relance le test avec le couple TC_LFR_UPDATE_TIME + 1 timecode = 1, cela<br />fonctionne systématiquement.</p>
<p>Ma conclusion est donc que la remise à zero du timecode géré par le spw n'est effectuée que sur le reset et que meme si je ferme socexplorer<br />je conserve la valeur du dernier timecode que j ai envoyé.</p>
<p>Pour valider cette conclusion, j'ai lu la doc grlib.pdf de Gaisler et j'ai été aidé par Alexis.</p>
<p>J'ai donc écrit un petit script qui lit le registre nommé Time register (0x800000514) dans l'onglet GRSPW et qui contient sur 8 bits <br />- Time control flags (TCTRL) = 2 bits = b7 et b6<br />- Time counter (TIMECNT) = 6 bits = b5 à b0<br />Attention, cela correspond à la valeur du dernier timecode valide et non le nbre de timecode valides. Ce registre n'est accessible qu'en lecture et il est à l'adresse<br />0x800000514</p>
<p>Pour le lire, j ai utilisé la fonction SpwPlugin0.Read <br />et ma théorie s'est vérifiée, quand on sort de socexplorer , il y a conservation de ce registre.</p>
<p>Conclusion, avant d'envoyer un time code,<br />1- il faut lire la valeur contenue dans 0x800000514<br />2- incrementer cette valeur et l envoyer avec SpwPlugin0.StarDundeeSendOneTimecode</p>
<p>Voici donc la séquence à mettre<br />Lecture du timer counter<br />loc_time = SpwPlugin0.Read(0x80000514, 1)<br />timec = loc_time<sup><a href="#fn0">0</a></sup> & 0xff<br />print hex(timec)</p>
<p>timecode=int(timec)+2<br />print timecode<br />SpwPlugin0.StarDundeeSendOneTimecode (timecode)</p>
<p>Remarque<br />--------<br />Comme on ne s interesse pas aux 2 bits de controles, <strong>le masque devrait etre 3f au lieu de ff.</strong><br />En effet les timecodes sont modulo 64.<br />Je l'ai egalement vérifié si j'ecris SpwPlugin0.StarDundeeSendOneTimecode (255) et que je lis le registre, j obtiens en binaire 00111111 soit 3f<br />soit 63.</p>
<p>Autre test, j ai envoyé la sequence suivante<br />py > SpwPlugin0.StarDundeeSendOneTimecode (6)<br />py > SpwPlugin0.StarDundeeSendOneTimecode (254)<br />py > SpwPlugin0.StarDundeeSendOneTimecode (255)</p>
<p>--> le registre ne s'est mis à jour que lors de l'envoi de 255 , car 6 n'etait pas valide, 254 pas valide<br />mais 255 oui car increment de 1/ à la valeur précédente.</p>
<p>Voila ma conclusion. <br />Par contre, on voit bien que 254 a été conservé puisque 255 a été validé, mais je ne sais pas ou ???</p> LFR-FSW - Support #486 (Feedback): SSS-CP-FS-340 : Design or Testhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/4862015-08-18T06:46:10ZVeronique bouzid
<p>Hello,<br />Je m'interroge sur ce requirement<br />SSS-CP-FS-340<br />The RPW Flight Software shall maintain a local time with:<br />− a resolution of at least SY_RPW_TIME_RESOLUTION = 1 ms and a relative accuracy of<br /> SY_RPW_TIME_ACCURACY = 500 μs for the DAS and the three analyzers.<br />− a resolution of at least SY_DPU_DBS_TIME_RESOLUTION = 10 ms and a relative<br /> accuracy of SY_DPU_DBS_TIME_ACCURACY = 1 ms for the DBS.</p>
<p>Il est associé dans la SRS à REQ-LFR-SRS-5300_Ed2.<br />Dans notre fichier SSS-SRS-SVS-compliance_matrix_LFR_V2-1.2.xlsx , il apparait comme un test SVS-0020. Le script associé <br />est time_resolution.py (ce qui ne correspond pas à ce qui est ecrit dans le fichier ). Le nom est internal_time_consistent.py,<br />qui est un script de dépouillement.</p>
<p>Ma question est la suivante, <br />Je ne vois pas comment vérifier ce requirement et pour moi, c'est un test de Design.</p>
<p>J ai assigné ce point à Paul et mis Bruno en observateur ainsi que moi.</p> LFR-FSW - Support #473 (Closed): R3 *** Adapter les scripts aux exigences https://hephaistos.lpp.polytechnique.fr/redmine/issues/4732015-07-17T14:15:59ZVeronique bouzid
<p>La Feature <a class="issue tracker-2 status-5 priority-2 priority-default closed" title="Feature: R3 *** mise en conformité avec l'IDC rev 3.7 (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/386">#386</a> indique :<br />Mise en conformité du logiciel de vol avec l'ICD rev 3.7.<br />Mise à jour de toutes les tailles de paquets et des paramètres d'identification des paquets (pid, cat, type, subtype, sid, length).</p>
<p>Il faut donc identifier les scripts qui sont concernés</p>
<p>- SVS-0002 Detection des TM_LFR_SCIENCE_SWF_F0, TM_LFR_SCIENCE_ASM_F0, TM_LFR_SCIENCE_CWF_F1 --> subtype a changé = 6 au lieu de 3<br />- SVS-0003 rajout de 3 Commandes <strong>tc_lfr_dump_kcoeff tc_lfr_load_kcoeff tc_lfr_fbins_mask</strong> <br />- SVS-0005 rajout de 3 Commandes <strong>tc_lfr_dump_kcoeff tc_lfr_load_kcoeff tc_lfr_fbins_mask</strong><br />- SVS-0007 rajout de 3 Commandes <strong>tc_lfr_dump_kcoeff tc_lfr_load_kcoeff tc_lfr_fbins_mask</strong><br />- SVS-0008 rajout de 3 Commandes <strong>tc_lfr_dump_kcoeff tc_lfr_load_kcoeff tc_lfr_fbins_mask</strong><br />- SVS-0009 rajout de 3 Commandes <strong>tc_lfr_dump_kcoeff tc_lfr_load_kcoeff tc_lfr_fbins_mask</strong><br />- SVS-0010 rajout de 3 Commandes <strong>tc_lfr_dump_kcoeff tc_lfr_load_kcoeff tc_lfr_fbins_mask</strong></p> LFR-FSW - Support #399 (Closed): Mode Standby durant 3s à la fin des testshttps://hephaistos.lpp.polytechnique.fr/redmine/issues/3992015-04-30T08:12:39ZVeronique bouzid
<p>Pour permettre de verifier le parametre HK_LFR_DPU_SPW_PKT_SENT_CNT,<br />il faut attendre 2 ou 3 secondes au début pour observer les TM_LFR_HK <br />et terminer le test en Standby en attendant egalement 2 à 3s.</p>
<p>Le nbre de packets envoyés sera calculé de la facon suivante<br />Nbre_packets_sent = HK_LFR_DPU_SPW_PKT_SENT_CNT du dernier HK - HK_LFR_DPU_SPW_PKT_SENT_CNT du premier HK + 1</p>
<p>Cette valeur est calculée dans le script verif_fields et ecrit dans le fichier sss_cp_eqs_050.txt.</p>
<p>Ensuite on peut calculer le nbre de TM recus dans le fichier Detail avec la commande<br />grep "TM_LFR" fichier-Detail.txt</p>
<p>Cette méthode de comparaison permet de verifier que tous mles packets envoyés sont bien transmis au DPU. Paul nous conseille cette<br />démarche car verifier pour chaque HK peut montrer des differences dus à la mise en file d 'attente des TM générées par LFR et qui respectent <br />la chronologie temporelle.</p>
<p>1- SVS-0018/my_source_id_loop_shortasm.py est à modifier</p> Solar Orbiter LFR - Support #258 (Closed): Numéro de version du code VHDLhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/2582014-10-27T15:43:04ZAlexis Jeandet
<p>Véronique a soulevé une question pertinente, versionner le code VHDL n'est peut être pas suffisant si les contraintes ne sont pas prises en compte.<br />Une piste serait d'incrémenter de numéro de version du VHDL à chaque nouveau bitstream surtout si les contraintes ont explicitement changé.<br />Peut être que c'est déjà le cas?</p> LFR-FSW - Support #181 (Closed): Impossibilité de provoquer un TM_LFR_EXE_ERRORhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/1812014-07-03T09:46:00Zbruno katra
<p><a class="external" href="https://jira-lesia.obspm.fr/browse/RPWSWR-448?jql=text%20~%20%22EXE_ERROR%22">https://jira-lesia.obspm.fr/browse/RPWSWR-448?jql=text%20~%20%22EXE_ERROR%22</a></p>