Redmine: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012023-01-19T10:26:55ZRedmine
Redmine LFR-FSW - Bug #4012 (Closed): TM_LFR_KCOEFFICIENTS_DUMP erroné suite à l'envoi d'une TC_LFR_LOAD_...https://hephaistos.lpp.polytechnique.fr/redmine/issues/40122023-01-19T10:26:55ZVeronique bouzid
<p>Dans le test /opt/VALIDATION_R3.3/lfrverif/LFR_SVS/SVS-0086/load_kcoeff_with_dump_v3-3.py</p>
<p>l'envoi d'un TC_LFR_LOAD_KCOEFFICIENTS avec KCOEFF_FREQ = 0, KCOEFF_1 = 1065353216 à KCOEFF_32 = 1065353216<br /> ne doit pas modifier les KCOEFF contenus dans la TM_LFR_KCOEFFICIENTS_DUMP.</p>
<p>Extrait</p>
<p><strong>TM_LFR_KCOEFFICIENTS_DUMP</strong> , CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: FUNCTIONAL_NON_CYCLIC = 6, (PACKET_ID=0xcc6), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=2, (PACKET_SEQUENCE_CONTROL=0xc002), PACKET_LENGTH=3393, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: KCOEFFICIENTS_DUMP = 96, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x8000000d233f, PA_LFR_HK_SID: LFR_KCOEFF_SID = 11, PA_LFR_KCOEFF_PKT_CNT=2, PA_LFR_KCOEFF_PKT_NR=1, PA_LFR_KCOEFF_BLK_NR=26, <strong>SY_LFR_KCOEFF_FREQUENCY=0, SY_LFR_KCOEFF_1=1065353216, SY_LFR_KCOEFF_2=1065353216, SY_LFR_KCOEFF_3=1065353216, SY_LFR_KCOEFF_4=1065353216, SY_LFR_KCOEFF_5=1065353216, SY_LFR_KCOEFF_6=1065353216, SY_LFR_KCOEFF_7=1065353216, SY_LFR_KCOEFF_8=1065353216, SY_LFR_KCOEFF_9=1065353216, SY_LFR_KCOEFF_10=1065353216, SY_LFR_KCOEFF_11=1065353216, SY_LFR_KCOEFF_12=1065353216, SY_LFR_KCOEFF_13=1065353216, SY_LFR_KCOEFF_14=1065353216, SY_LFR_KCOEFF_15=1065353216, SY_LFR_KCOEFF_16=1065353216, SY_LFR_KCOEFF_17=1065353216, SY_LFR_KCOEFF_18=1065353216, SY_LFR_KCOEFF_19=1065353216, SY_LFR_KCOEFF_20=1065353216, SY_LFR_KCOEFF_21=1065353216, SY_LFR_KCOEFF_22=1065353216, SY_LFR_KCOEFF_23=1065353216, SY_LFR_KCOEFF_24=1065353216, SY_LFR_KCOEFF_25=1065353216, SY_LFR_KCOEFF_26=1065353216, SY_LFR_KCOEFF_27=0, SY_LFR_KCOEFF_28=0, SY_LFR_KCOEFF_29=0, SY_LFR_KCOEFF_30=0, SY_LFR_KCOEFF_31=0, SY_LFR_KCOEFF_32=0</strong></p>
<p>On voit bien que seuls les KCOEFF allant de 1 à 26 ont récupéré la valeur modifiée par la TC_LFR_LOAD_KCOEFFICIENTS_alors que les KCOEFF de 27 à 32 sont bien restés à zéro (valeurs par défaut mises au boot).</p>
<p><ins>Ici les valeurs de référence récupérées au boot</ins></p>
<p><strong>TM_LFR_KCOEFFICIENTS_DUMP</strong> , CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: FUNCTIONAL_NON_CYCLIC = 6, (PACKET_ID=0xcc6), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=0, (PACKET_SEQUENCE_CONTROL=0xc000), PACKET_LENGTH=3393, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: KCOEFFICIENTS_DUMP = 96, DESTINATION_ID: MISSION_TIMELINE = 110, PA_LFR_HK_SID: LFR_KCOEFF_SID = 11, PA_LFR_KCOEFF_PKT_CNT=2, PA_LFR_KCOEFF_PKT_NR=1, PA_LFR_KCOEFF_BLK_NR=26, <strong>SY_LFR_KCOEFF_FREQUENCY=0, SY_LFR_KCOEFF_1=1050859893, SY_LFR_KCOEFF_2=1051774863, SY_LFR_KCOEFF_3=3199048410, SY_LFR_KCOEFF_4=3199675526, SY_LFR_KCOEFF_5=1048105208, SY_LFR_KCOEFF_6=1049731468, SY_LFR_KCOEFF_7=3199884855, SY_LFR_KCOEFF_8=3201093691, SY_LFR_KCOEFF_9=1002946415, SY_LFR_KCOEFF_10=993270132, SY_LFR_KCOEFF_11=1052396741, SY_LFR_KCOEFF_12=1051678457, SY_LFR_KCOEFF_13=3193633745, SY_LFR_KCOEFF_14=3195990147, SY_LFR_KCOEFF_15=3202344225, SY_LFR_KCOEFF_16=3204016481, SY_LFR_KCOEFF_17=3191761623, SY_LFR_KCOEFF_18=3194781000, SY_LFR_KCOEFF_19=0, SY_LFR_KCOEFF_20=2147483648, SY_LFR_KCOEFF_21=3164388996, SY_LFR_KCOEFF_22=3169957665, SY_LFR_KCOEFF_23=3164388996, SY_LFR_KCOEFF_24=3169957665, SY_LFR_KCOEFF_25=3156000388, SY_LFR_KCOEFF_26=3161569057, SY_LFR_KCOEFF_27=0, SY_LFR_KCOEFF_28=0, SY_LFR_KCOEFF_29=0, SY_LFR_KCOEFF_30=0, SY_LFR_KCOEFF_31=0, SY_LFR_KCOEFF_32=0</strong></p>
<p><strong>QUESTION<br />----------------<br />Est ce un bug ou bien le comportement attendu?</strong></p>
<p>Contexte du test<br />----------------------<br />FSW 3.3.0.11 et 3.3.0.12<br />VHDL 1.1.91<br />EM2 sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = 0.6, Changeset = c459540a6dbd+<br />StarDundee</p> LFR-FSW - Task #1059 (Closed): Livraison SDDhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/10592017-04-12T10:11:04ZVeronique bouzid
<p>Pour le datapack, il faut fournir le SDD.<br />Il nous faudrait le document pour le 30 avril 2017 au plus tard.</p> LFR-FSW - Bug #981 (Closed): TC_LFR_LOAD_FILTER_PAR not acknowledgedhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/9812017-03-16T09:19:03ZVeronique bouzid
<p>Le script utilisé est /home/validation/SCRIPT/R3++/set_load_filter_par.py.<br />L'envoi d une TC_LFR_LOAD_FILTER_PAR n est pas acquittée</p>
<p>09:56:29.206898,/home/validation/SCRIPT/R3++/set_load_filter_par.py<br />09:56:31.208759,PROXY LOAD is True<br />09:56:45.225339, /!\No TM_LFR_TC_EXE_* after time-out (4s).<br />09:56:50.226504, /!\No TM_LFR_TC_EXE_* after time-out (4s).<br />09:57:02.227914, /!\No TM_LFR_TC_EXE_* after time-out (4s).<br />09:57:07.228961, /!\No TM_LFR_TC_EXE_* after time-out (4s).<br />09:57:12.229741,End(/home/validation/SCRIPT/R3++/set_load_filter_par.py)</p>
<p>Les fichiers de données (2017_03_16-09_57_12*) sont rangés dans /home/validation/data/R3++/3.2.0.3/1.1.91/TEST-UNITAIRES/set_load_filter_par.</p>
<p>Contexte du test<br />----------------<br />FSW 3.2.0.3<br />VHDL 1.1.91<br />EM1 sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = 0.6, Changeset = c459540a6dbd+<br />StarDundee</p> LFR-FSW - Bug #976 (Closed): HK_LFR_SC_V_F3 is erroneous https://hephaistos.lpp.polytechnique.fr/redmine/issues/9762017-03-13T14:04:08ZVeronique bouzid
<p>Envoi de N rampes durant 2 mn avec balayage complet de la dynamique (-3.3V à 3.3V).</p>
<p>Nous avons verifié que la decomm fonctionnée donc le probleme doit venir du software de LFR.</p>
<p>Je joins le fichier qui plotte le champ HK_LFR_SC_V_F3 (RampUp_2mn_on_V.png)</p>
<p>le fichier utilisé par les plots est également fourni.</p> LFR-FSW - Bug #907 (Closed): TC_LFR_LOAD_KCOEFFICIENTS plante le logicielhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/9072017-01-17T10:37:31ZVeronique bouzid
<p>En voulant lancer le script loop_tm_lfr_tc_exe.py qui envoietoutes les TC, le script a planté le soft.</p>
<p>J ai donc identifié la TC en cause qui est TC_LFR_LOAD_KCOEFFICIENTS</p>
<p>voici la trace du fichier 2017_01_17-11_24_54-Synth.txt<br />11:24:38.273163, TM_LFR_HK, TIME=0x8000001a66a1<br />11:24:39.068631, TC_LFR_ENTER_MODE (CP_LFR_MODE=0)<br />11:24:39.104208, TM_LFR_TC_EXE_NOT_EXECUTABLE, TIME=0x8000001b3b93<br />11:24:39.273157, TM_LFR_HK, TIME=0x8000001b66a1<br />11:24:40.273184, TM_LFR_HK, TIME=0x8000001c66a1<br /><strong>11:24:41.104588, TC_LFR_LOAD_KCOEFFICIENTS</strong><br />11:24:45.105708, TC_LFR_ENTER_MODE (CP_LFR_MODE=0)</p>
<p>--> suite à l envoi aucune réponse et dans la console socexe , indication du time out de 4s donc voici la trace (2017_01_17-11_24_54-Nb.txt)</p>
<p>11:24:32.064334,/opt/VALIDATION_R3plus/lfrverif/LFR_SVS/SVS-0003/send_one_tc_load_kcoeff.py<br />11:24:34.066478,PROXY LOAD is False<br />11:24:45.104676,* /!\No TM_LFR_TC_EXE_* after time-out (4s).*<br />11:24:49.105767, /!\No TM_LFR_TC_EXE_* after time-out (4s).<br />11:24:54.106518,End(/opt/VALIDATION_R3plus/lfrverif/LFR_SVS/SVS-0003/send_one_tc_load_kcoeff.py)</p>
<p>je joins au redmine le script pour que tu testes de ton coté.</p>
<p>Les fichiers (2017_01_17-11_24_54-*) sont rangés dans le répertoire /home/validation/data/R3+/3.1.0.5/3.1.91/TESTS-UNITAIRES/send_one_tc_load_kcoeff</p>
<p>Contexte du test<br />---------------------<br />FSW 3-1-0-5-Rev331<br />VHDL 3.1.91<br />PFM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = 0.6, Changeset = c459540a6dbd+<br />StarDundee</p> LFR-FSW - Bug #867 (Closed): Fonction setFBinMask: Calcul masque erroné https://hephaistos.lpp.polytechnique.fr/redmine/issues/8672016-12-29T11:44:23ZVeronique bouzid
<p>J ai testé la fonction serFBinMask avec les parametres décrits ci-dessous<br />setFBinMask( fbins_mask, rw_f, deltaFreq, flag );</p>
<p>rw_f = 96.0<br />deltaFreq= 96.0</p>
<p>flag=1</p>
<p>Voila la trace du calcul</p>
<p>--> on trouve 3 bins à masquer 0,1,2<br /><strong>Channel = 0 and Freq = 96.000000</strong><br />binBelow = 1 and binAbove = 1<br />closestBin = 1<br /><strong>bin0 = 0 and bin1= 1 and bin2= 2</strong></p>
<p><ins>le premier masque calculé pour le bin 0</ins><br /> Byte Range is 15 and previous mask is 0xff (condition initiale)<br /> Byte Range is 15 and mask is 0xfe le maque calculé<br />au final<br /> <strong>Byte Range is 15 and current mask is 0xfe</strong></p>
<p><ins>le masque calculé pour le bin 1</ins><br /> Byte Range is 15 and previous mask is 0xfe<br /> Byte Range is 15 and mask is 0xfc le masque calculé<br /> <strong>Byte Range is 15 and current mask is 0xfc</strong></p>
<p>l+e masque calculé pour le bin 2+<br /> Byte Range is 15 and previous mask is 0xfc<br /> Byte Range is 15 and mask is 0xf8 le masque calculé<br /> Byte Range is 15 and current mask is 0xf8</p>
<p>et ensuite le tour en plus lié au k=3<br /> Byte Range is 15 and previous mask is 0xf8<br /> Byte Range is 15 and mask is 0xf8<br /> Byte Range is 15 and current mask is 0xf8</p>
<p>On obtient donc pour rw_f=96 hz et le channel 0, le masque suivant<br />Byte Range is 15 and current mask is 0xf8 ce qui signifie que les 3</p>
<p>Hors le tableau des frequences à F0 est le suivant <br />F0 <br />[ <strong>96 192</strong> 288 384 480 576 672 768<br /> 864 960 1056 1152 1248 1344 1440 1536<br /> 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<br /> 10080 10176 10272 10368 10464 10560 10656 10752<br /> 10848 10944 11040 11136 11232 11328 11424 11520<br /> 11616 11712 11808 11904 12000 12096 12192 12288]</p>
<p>et donc on devrait obtenir comme <strong>masque 0xfc</strong> puisque que 96 et 192 doivent etre masquées.</p>
<p>Je rappelle que la fréquence 0 n est pas à considérer comme indiqué dans le REQ-RPW-LFR-2407 du document RPW-MEB-LFR-00003 (Technical specifications)</p> LFR-FSW - Bug #865 (Closed): Fonction setFBinMask erronéehttps://hephaistos.lpp.polytechnique.fr/redmine/issues/8652016-12-29T10:56:07ZVeronique bouzid
<p>Pour avancer sur l'analyse du bug <a class="issue tracker-1 status-5 priority-4 priority-high2 closed" title="Bug: Mauvais BIN filtrée suite à reception d'un UPDATE_INFO avec les fréquences RW : décalage de 1 (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/864">#864</a> , je me suis permise de récuperer ta fonction setFBinMask et de la tester unitairement.</p>
<p>1- Cette boucle est erronée , la derniere valeur de k doit etre 2 et non 3<br /> for (k = 0; k <= 3; k++)
{<br /> bin = binToRemove[k];</p>
<p>--> la declaration du tableau est int binToRemove[ 3 ];<br />Si on a 3 bins à enlever tu vas superposer 4 masques.</p> LFR-FSW - Bug #657 (Closed): HK_LFR_xE_CNT doesn't manage the wrap of 8bits counter errorhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/6572016-03-09T14:28:44ZVeronique bouzid
<p>En Analysant le passage à zero des compteurs d'erreurs suivants (HK_LFR_TIMECODE_MISSING et HK_LFR_TIME_NOT_SYNCHRO, j observe bien le passage de 255 vers 0<br />pour les compteurs d'erreur codés sur 8 bits mais l'effet non attendu est que les compteurs HK_LFR_xE_CNT qui eux sont codés sur 16 bits ne sont plus bons car<br />ils representent la somme des erreurs liées à une criticité et donc le fait qu'un compteur passe à 0 diminue la valeur du ce compteur HK_LFR_xE_CNT<br />Voici un extrait du fichier Detail.txt</p>
<p>15:54:46.122923, TM_LFR_HK, TIME=0x000000ff81da, HK_LFR_UPDATE_TIME_TC_CNT=255, <strong>HK_LFR_LE_CNT=509,</strong> HK_LFR_ME_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIME = 42119, HK_LFR_LAST_ER_CODE: NOT_SYNCHRO = 25, HK_LFR_LAST_ER_TIME=0x8000013bd189, HK_LFR_DPU_SPW_TICK_OUT_CNT=255, HK_LFR_DPU_SPW_LAST_TIMC=63, HK_LFR_DPU_SPW_PARITY=0, HK_LFR_DPU_SPW_DISCONNECT=0, HK_LFR_DPU_SPW_ESCAPE=0, HK_LFR_DPU_SPW_CREDIT=0, HK_LFR_DPU_SPW_WRITE_SYNC=0, HK_LFR_DPU_SPW_RX_AHB=0, HK_LFR_DPU_SPW_TX_AHB=0, HK_LFR_DPU_SPW_EARLY_EOP=0, HK_LFR_DPU_SPW_INVALID_ADDR=0, HK_LFR_DPU_SPW_EEP=0, HK_LFR_DPU_SPW_RX_TOO_BIG=0, HK_LFR_TIMECODE_ERRONEOUS=0, <strong>HK_LFR_TIMECODE_MISSING=255</strong>, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, <strong>HK_LFR_TIME_NOT_SYNCHRO=254,</strong> HK_LFR_TIME_TIMECODE_CTR=0</p>
<p>15:54:47.122944, TM_LFR_HK, TIME=0x0000010081da, HK_LFR_UPDATE_TIME_TC_CNT=255, <strong>HK_LFR_LE_CNT=254,</strong> HK_LFR_ME_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIMEC = 42129, HK_LFR_LAST_ER_CODE: MISSING = 21, HK_LFR_LAST_ER_TIME=0x000001003270, HK_LFR_DPU_SPW_TICK_OUT_CNT=255, HK_LFR_DPU_SPW_LAST_TIMC=63, HK_LFR_DPU_SPW_PARITY=0, HK_LFR_DPU_SPW_DISCONNECT=0, HK_LFR_DPU_SPW_ESCAPE=0, HK_LFR_DPU_SPW_CREDIT=0, HK_LFR_DPU_SPW_WRITE_SYNC=0, HK_LFR_DPU_SPW_RX_AHB=0, HK_LFR_DPU_SPW_TX_AHB=0, HK_LFR_DPU_SPW_EARLY_EOP=0, HK_LFR_DPU_SPW_INVALID_ADDR=0, HK_LFR_DPU_SPW_EEP=0, HK_LFR_DPU_SPW_RX_TOO_BIG=0, HK_LFR_TIMECODE_ERRONEOUS=0, <strong>HK_LFR_TIMECODE_MISSING=0,</strong> HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, <strong>HK_LFR_TIME_NOT_SYNCHRO=254</strong>, HK_LFR_TIME_TIMECODE_CTR=0</p>
<p>Ceci est donc valable pour n'importe quel compteur codé sur 8 bits et utilisé dans une somme.</p>
<p>Les fichiers (2016_02_25-16_00_04-) sont dans /home/validation/data/R3/3.0.0.22/1.1.89/SVS-0078/not_synchro.<br />Probleme remonté en lancant verif_fields sur le fichier Detail.txt.<br />Le fichier sss_cp_eqs_050.txt met en evidence les observations et permet de valider les passages à zero des compteurs :</p>
<p>15:54:47.122944, TM_LFR_HK<br />HK_LFR_LE_CNT: res=254; exp>=509 HK_LFR_TIMECODE_MISSING: res=0; exp>=255</p>
<p>15:55:49.123074, TM_LFR_HK<br />HK_LFR_DPU_SPW_TICK_OUT_CNT: res=0; exp>=255 HK_LFR_DPU_SPW_LAST_TIMC: res=0; exp>=63</p>
<p>15:56:50.123381, TM_LFR_HK<br />HK_LFR_LE_CNT: res=1; exp>=256 HK_LFR_TIME_NOT_SYNCHRO: res=0; exp>=255</p>
<p>Le script utilisé se nomme /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0078/update_time_not synchro_cnt_wrap.py.</p>
<p>Contexte du test<br />---------------------<br />FSW 3.0.0.22<br />VHDL 1.1.89<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 #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 - Bug #529 (Closed): WRONG SEQUENCE_CNT on PACKET_ID=0xcfc https://hephaistos.lpp.polytechnique.fr/redmine/issues/5292015-10-02T10:55:17ZVeronique bouzid
<p>En jouant le script /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0031/sbm1_mode_parameter_set.py (cf #BUG484)<br />un autre BUG a été découvert concernant la gestion de SEQUENCE_CNT.</p>
<p>Les TM dont le PACKET_ID=0xcfc sont comptabilisées avec les TM dont le PACKET_ID=0xcc1</p>
<p>Voici un extrait du fichier 2015_10_02-08_51_52-Extract-seq-cnt.txt</p>
<p>07:46:40.814751, TM_LFR_HK, TIME=0x8000005731b2, PACKET_ID=0xcc4, SEQUENCE_CNT=85<br />07:46:41.352476, TC_LFR_ENTER_MODE, SOURCE_ID: MISSION_TIMELINE = 110<br />07:46:41.376684, <strong>TM_LFR_TC_EXE_NOT_EXECUTABLE, TIME=0x80000057c1bc, PACKET_ID=0xcc1, SEQUENCE_CNT=0</strong><br />07:46:41.814619, TM_LFR_HK, TIME=0x8000005831b3, PACKET_ID=0xcc4, SEQUENCE_CNT=86<br />07:46:42.814729, TM_LFR_HK, TIME=0x8000005931b3, PACKET_ID=0xcc4, SEQUENCE_CNT=87<br />07:46:43.382035, TC_LFR_LOAD_NORMAL_PAR, SOURCE_ID: MISSION_TIMELINE = 110<br />07:46:43.395366, <strong>TM_LFR_TC_EXE_SUCCESS, TIME=0x80000059c656, PACKET_ID=0xcc1, SEQUENCE_CNT=1</strong><br />07:46:43.582184, TC_LFR_DUMP_PAR, SOURCE_ID: MISSION_TIMELINE = 110<br />07:46:43.58804, TM_LFR_PARAMETER_DUMP, TIME=0x80000059f79b, PACKET_ID=0xcc6, SEQUENCE_CNT=0<br />07:46:43.590036, <strong>TM_LFR_TC_EXE_SUCCESS, TIME=0x80000059f7a3, PACKET_ID=0xcc1, SEQUENCE_CNT=2</strong><br />07:46:43.782329, TC_LFR_ENTER_MODE, SOURCE_ID: MISSION_TIMELINE = 110<br />07:46:43.807095, <strong>TM_LFR_TC_EXE_SUCCESS, TIME=0x8000005a2fc0, PACKET_ID=0xcc1, SEQUENCE_CNT=3</strong><br />07:46:43.828805, TM_LFR_HK, TIME=0x8000005a355d, PACKET_ID=0xcc4, SEQUENCE_CNT=88<br />07:46:44.085544, <strong>TM_LFR_SCIENCE_SBM1_BP1_F0, TIME=0x8000005a2fbf, PACKET_ID=0xcfc, SEQUENCE_CNT=4</strong><br />07:46:44.351218, TM_LFR_SCIENCE_SBM1_BP1_F0, TIME=0x8000005a6fbf, PACKET_ID=0xcfc, SEQUENCE_CNT=5<br />07:46:44.468572, TM_LFR_SCIENCE_SBM1_CWF_F1, TIME=0x8000005a2fb7, PACKET_ID=0xcfc, SEQUENCE_CNT=6<br />07:46:44.476022, TM_LFR_SCIENCE_SBM1_CWF_F1, TIME=0x8000005a44b7, PACKET_ID=0xcfc, SEQUENCE_CNT=7<br />07:46:44.489938, TM_LFR_SCIENCE_SBM1_CWF_F1, TIME=0x8000005a59b7, PACKET_ID=0xcfc, SEQUENCE_CNT=8<br />07:46:44.503171, TM_LFR_SCIENCE_SBM1_CWF_F1, TIME=0x8000005a6eb7, PACKET_ID=0xcfc, SEQUENCE_CNT=9<br />07:46:44.509066, TM_LFR_SCIENCE_SBM1_CWF_F1, TIME=0x8000005a83b7, PACKET_ID=0xcfc, SEQUENCE_CNT=10<br />07:46:44.51558, TM_LFR_SCIENCE_SBM1_CWF_F1, TIME=0x8000005a98b7, PACKET_ID=0xcfc, SEQUENCE_CNT=11<br />07:46:44.521673, TM_LFR_SCIENCE_SBM1_CWF_F1, TIME=0x8000005aadb7, PACKET_ID=0xcfc, SEQUENCE_CNT=12<br />07:46:44.535162, TM_LFR_SCIENCE_SBM1_CWF_F1, TIME=0x8000005ac2b7, PACKET_ID=0xcfc, SEQUENCE_CNT=13<br />07:46:44.585458, TM_LFR_SCIENCE_SBM1_BP1_F0, TIME=0x8000005aafbf, PACKET_ID=0xcfc, SEQUENCE_CNT=14</p>
<p>Contexte du test<br />----------------<br />FSW 3.0.0.9<br />VHDL 1.1.89<br />EM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />StarDundee</p> LFR-FSW - Bug #490 (Closed): [JIRA] (RPWMEB-495) LFR doesn't detect the TIME_TIMECODE_CTR errorshttps://hephaistos.lpp.polytechnique.fr/redmine/issues/4902015-09-09T11:42:00ZVeronique bouzid
<p>METTRE A JOUR SRS <br />-------------------<br />Voici un point JIRA datant du 09/Sep/15 9:31 AM</p>
<p>See the test log AT_2015-09-07_16-18-51</p>
<p>From 16:44:58, the time message (S9) sent by the DAS to the analyzers each second is no more synchronized with the time-code value. THR and TDS detect the problem and increment properly the HK_xxx_TIME_TIMECODE_CTR counter.<br />This is not the case of LFR for which the HK_LFR_TIME_TIMECODE_CTR remains stuck to 0.</p>
<p>Moreover, the failure is no traced in the ANOMALY_STATISTICS parameters.</p>
<p>See for example the packet TM_LFR_HK dated from 16:45:04</p> LFR-FSW - Bug #247 (Closed): Le champ TIME des TM (Cuc) reste à 0x800000000001https://hephaistos.lpp.polytechnique.fr/redmine/issues/2472014-10-15T11:32:19ZVeronique bouzid
<p>Suite à la modification de Paul (Target logical ID = 0x20) pour utiliser la STarDundee en mode routeur<br />le champ TIME des TM_LFR reste poistionnée à la valeur suivante 0x800000000001.</p>
<p>Les fichiers de log sont dans /home/validation et commencent par 2014_10_15-11_34_38.<br />Le script utilisé est /home/validation/SCRIPT/just_normal_mode.py.</p>
<p>Contexte de test<br />LFR_FSW_PATH = /opt/LFR-FSW/2.0.1.1/fsw<br />Bridge selection = StarDundee<br />SocExplorerEngine.getSocExplorer: Version = 0.2.2, Branch = default, Changeset = c839740ef520</p>
<p>Carte EM.</p> LFR-FSW - Bug #177 (Closed): EM : Envoi TC_LFR_LOAD_SBMx_PARAM est interdit en mode SBM1 et SBM2 https://hephaistos.lpp.polytechnique.fr/redmine/issues/1772014-06-20T07:43:37ZVeronique bouzid
<p>EN mode SBM1 et SBM2, on ne peut envoyer de TC_LFR_LOAD_SBM1_PARAM et TC_LFR_LOAD_SBM2_PARAM.<br />Gérald a décrit un tableau dans le requirement REQ-LFR-SRS-5207_Ed1 qui récapitule<br />ce que les TC autorisées en fct du mode de LFR et celui du DAS.</p>
<p>--> Il faut donc générer des TM_LFR_TC_EXE_NOT_EXECUTABLE au lieu des TM_LFR_TC_EXE_SUCCESS<br />Voici les traces<br />en SBM1<br />on ne doit pas accepter de changer les parametres du SBM2<br />--> repondre TM_LFR_TC_EXE_NOT_EXECUTABLE et non une TM_LFR_TC_EXE_SUCCESS</p>
<p>14:21:30.394448, TM_LFR_HK, HK_LFR_MODE: SBM1 = 3<br />14:21:30.803258, TC_LFR_LOAD_SBM2_PAR, 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=9018, (PACKET_SEQUENCE_CONTROL=0xe33a), PACKET_LENGTH=7, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=0, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: LOAD_SBM2_PARAMETERS = 27, SOURCE_ID: MISSION_TIMELINE = 110, SY_LFR_S2_BP_P0 = 1, SY_LFR_S2_BP_P1 = 5, CRC = 0x76fa</p>
<p>14:21:30.894486, TM_LFR_TC_EXE_SUCCESS, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: ACKNOWLEDGE = 1, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=111, (PACKET_SEQUENCE_CONTROL=0xc06f), PACKET_LENGTH=13, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_SUCCESS = 7, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x8000001cbbc3, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xe33a</p>
<p>on ne doit pas accepter de changer les parametres du SBM1<br />--> repondre TM_LFR_TC_EXE_NOT_EXECUTABLE et non une TM_LFR_TC_EXE_SUCCESS</p>
<p>14:21:33.294332, TM_LFR_HK, HK_LFR_MODE: SBM2 = 4<br />14:21:33.697692, TC_LFR_LOAD_SBM1_PAR, 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=6413, (PACKET_SEQUENCE_CONTROL=0xd90d), PACKET_LENGTH=7, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=0, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: LOAD_SBM1_PARAMETERS = 25, SOURCE_ID: MISSION_TIMELINE = 110, SY_LFR_S1_BP_P0 = 0.25(s), SY_LFR_S1_BP_P1 = 1(s), CRC = 0xa7e5</p>
<p>14:21:33.794294, TM_LFR_TC_EXE_SUCCESS, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: ACKNOWLEDGE = 1, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=121, (PACKET_SEQUENCE_CONTROL=0xc079), PACKET_LENGTH=13, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_SUCCESS = 7, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x8000001f9e39, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xd90d</p>
<hr />
<p>Contexte:<br />SocExplorerEngine.getSocExplorer: Version = 0.2.2, Branch = default, Changeset = c839740ef520<br />Carte EM<br />Vhdl: EM_1.1.23<br />Brique Star-Dundee S/N <illisible>.<br />Soft:1.0.0.11 (variante sur carte finale)</p>
<p>TEST CASE = SVS-0007<br />le fichierd'analyse est /home/validation/data/R2/SVS-0007/2014_06_19-14_21_35-Detail.txt</p> LFR-FSW - Bug #166 (Closed): PACKET LENGTH erroné pour TM_LFR_SCIENCE_BURST_BP1_F1 et TM_LFR_SCIE...https://hephaistos.lpp.polytechnique.fr/redmine/issues/1662014-06-10T06:15:20ZVeronique bouzid
<p>EN analysant le fichier 2014_06_05-12_11_54-Detail.txt correspondant au test<br />SVS-0090/generate_science_all_modes.py<br />2 pbs sur le parametre PACKET LENGTH, la longueur du packet de telemetry ne correspond pas au champ contenu dans PACKET_LENGTH</p>
<p>- 16:42:38.053034, TM_LFR_SCIENCE_BURST_BP1_F0, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=3, (PACKET_SEQUENCE_CONTROL=0xc003), PACKET_LENGTH=217, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, TIME=0x80000025ac28, PA_LFR_SID_PKT: SC_B_BP1_F0 = 17, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, PA_BIA_ON_OFF: OFF = 0, PA_LFR_ACQUISITION_TIME=0x80000025ac28, PA_LFR_B_BP1_BLK_NR_F0=22<br />16:42:38.064438, TM_LFR_SCIENCE_BURST_BP1_F1, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=4, (PACKET_SEQUENCE_CONTROL=0xc004), <strong>/!\PACKET_LENGTH=217(exp=(Number of bytes in Packet Data Field)-1=253)</strong>.....</p>
<p>- 16:42:38.053034, TM_LFR_SCIENCE_BURST_BP1_F0, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=3, (PACKET_SEQUENCE_CONTROL=0xc003), PACKET_LENGTH=217, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, TIME=0x80000025ac28, PA_LFR_SID_PKT: SC_B_BP1_F0 = 17, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, PA_BIA_ON_OFF: OFF = 0, PA_LFR_ACQUISITION_TIME=0x80000025ac28, PA_LFR_B_BP1_BLK_NR_F0=22<br />16:42:38.064438, TM_LFR_SCIENCE_BURST_BP1_F1, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=4, (PACKET_SEQUENCE_CONTROL=0xc004), <strong>/!\PACKET_LENGTH=217(exp=(Number of bytes in Packet Data Field)-1=253)</strong>,</p>
<p>Ce probleme est présent sur d'autres tests (vu egalement sur 1.0.0.6)</p>
<p>Contexte<br />LPPMON Version = 0.2.2, Branch = default, Changeset = 835955994d5f<br />Carte mini-LFR: LFR-172200 dev V1.0; No série 5<br />Vhdl: 0.0.16<br />Soft: 1.0.0.7 (variante sur carte finale)</p>
<p>Brique Star-Dundee S/N <strong>XX</strong>.</p>