Redmine: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012017-03-16T10:31:33ZRedmine
Redmine LFR-FSW - Bug #982 (Closed): Verification SC_potention V_F3https://hephaistos.lpp.polytechnique.fr/redmine/issues/9822017-03-16T10:31:33ZVeronique bouzid
<p>Voici le plots obtenus lors de la crétion de la ramp 2mn sur V<br />Le plot vert = HK<br />Le plot fushia = CWF_F3</p>
<p>le temps du 1er HK est 55.0289154052734375<br />le temps de la premiere cwf_f3 est 55.9727478027343750</p>
<p>Les données sont rangées dans le répertoire /home/validation/data/R3++/3.2.0.3/1.1.91/SC_potential_mean_HK_datasets/RampUp_2mn_on_V.<br />Les données sont également sur le ftp<br /><a class="external" href="ftp://ftp.lpp.polytechnique.fr/bouzid/keep/LFR/3.2.0.3/SC_potential_mean_HK_datasets/RampUp_2mn_on_V">ftp://ftp.lpp.polytechnique.fr/bouzid/keep/LFR/3.2.0.3/SC_potential_mean_HK_datasets/RampUp_2mn_on_V</a></p> LFR-FSW - Task #615 (Stalled): Validation SWF 22s pour 3.0.0.20https://hephaistos.lpp.polytechnique.fr/redmine/issues/6152016-02-10T09:14:42ZVeronique bouzid
<p>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 donc<br />c'est plutot un tests de non regression.</p>
<p>Ce test enchaine<br />- 1800s de Normal mode<br />- 900s de SBM1<br />- 900s de SBM2<br />- 600s de NORMAL<br />- 600s de BURST<br />- 600s de NORMAL<br />- Fin en STANDBY</p>
<p>Les fichiers (2016_02_10_08_09_20*) sont stockés sur pc-instru /Weeklyerased/Thomas/run-2016-02-10-3.0.0.20-1.1.89/swf-22s<br />Les fichiers (2016_02_10_08_09_20_*) sont également sur pc-faust9 dans le répertoire /home/validation/data/R3/3.0.0.20/TESTS-UNITAIRES/all-modes</p>
<p>Contexte du test<br />---------------------<br />FSW 3.0.0.20<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 - Task #613 (Closed): Validation SWF 22s https://hephaistos.lpp.polytechnique.fr/redmine/issues/6132016-02-09T08:34:46ZVeronique bouzid
<p>Ce test enchaine<br />- 1800s de Normal mode<br />- 900s de SBM1<br />- 900s de SBM2<br />- 600s de NORMAL<br />- 600s de BURST<br />- 600s de NORMAL<br />- Fin en STANDBY</p>
<p>Il va permettre de vérifier la non discontinuite des produits NORMAL MODE indépendamment des transitions en SBM1, SBM2, NORMAL.<br />Lors du passage en burst, plus de produits<br />Lors du passage en NORMAL, verifier que tous les produits NORMAL reviennent correctement.</p>
<p>Les fichiers (2016_02_09_08_09_33_*) sont stockés sur pc-instru /Weeklyerased/Thomas/run-2016-02-09-3.0.0.19-1.1.89.<br />Les fichiers (2016_02_09_08_09_33_*) sont également sur pc-faust9 dans le répertoire /home/validation/data/R3/3.0.0.19/TEST-UNITAIRES/all-modes</p>
<p>Contexte du test<br />---------------------<br />FSW 3.0.0.19<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 #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 - Task #517 (Closed): Vérification des températureshttps://hephaistos.lpp.polytechnique.fr/redmine/issues/5172015-09-29T14:05:41ZVeronique bouzid
<p>J ai demandé à Paul comment calculer les temperatures contenues dans les TM_LFR_HK.</p>
<p>3 champs<br /> - HK_LFR_TEMP_SCM<br /> - HK_LFR_TEMP_PCB<br /> - HK_LFR_TEMP_FPGA</p>
<p>Voici sa réponse<br />Deux solutions: soit tu fais une vérification par toi même et dans ce cas, il faut regarder sur les schémas de la carte sur lesquels Alexis a glissé des plots dont on peut déduire les formules (tu peux lui demander de l'aide si t'as pas peur). Soit tu me fais confiance et dans le soft lfrsgse, la fonctino qui fait ça est la suivante:</p>
<p>void HKDisplay::update_temperatures(Packet_TM_LFR_HK_t *housekeepingPacket)
{<br /> short temp_scm;<br /> short temp_pcb;<br /> short temp_fpga;<br /> float Tscm;<br /> float Tpcb;<br /> float Tfpga;</p>
<pre><code>temp_scm = (short) (housekeepingPacket->hk_lfr_temp_scm[0] << 8)<br /> + housekeepingPacket->hk_lfr_temp_scm[1];<br /> temp_pcb = (short) (housekeepingPacket->hk_lfr_temp_pcb[0] << 8)<br /> + housekeepingPacket->hk_lfr_temp_pcb[1];<br /> temp_fpga = (short) (housekeepingPacket->hk_lfr_temp_fpga[0] << 8)<br /> + housekeepingPacket->hk_lfr_temp_fpga[1];</code></pre>
<pre><code>Tscm = ( (float) temp_scm) * 1.4 / 16384 * 100 / 0.8 + 115;<br /> Tpcb = ( (float) temp_pcb) * 1.4 / 16384 * 50 / 0.8 + 37.5;<br /> Tfpga = ( (float) temp_fpga)* 1.4 / 16384 * 50 / 0.8 + 37.5;</code></pre>
<pre><code>hk_lfr_temp_scm->setText( "temp_scm: " + QString::number( temp_scm )<br /> + " (" + QString::number( Tscm, 'f', 1 ) + " °C)");<br /> hk_lfr_temp_pcb->setText( "temp_pcb: " + QString::number( temp_pcb )<br /> + " (" + QString::number( Tpcb, 'f', 1 ) + " °C)");<br /> hk_lfr_temp_fpga->setText("temp_fpga: " + QString::number( temp_fpga )<br /> + " (" + QString::number( Tfpga, 'f', 1 ) + " °C)");<br />}</code></pre>
<p>En ce qui concerne la temperature des SCM, cela ne peut etre fait par pas de sensors.</p> LFR-FSW - Bug #515 (Closed): [JIRA] (RPWMEB-465) Status of HK_LFR_SC_POTENTIAL_FLAG in TM_LFR_HKhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/5152015-09-28T09:49:45ZVeronique bouzid
<p>During the last acceptance test compaign, an anomaly in TM_LFR_HK telemetry packet has been detected.</p>
<p>The value of parameter HK_LFR_SC_POTENTIAL_FLAG (related to spacecraft potential) is always FALSE, even during the production of TM_LFR_SCIENCE_NORMAL_CWF_F3 telemetry packets.</p>
<p>see: [RPWDPU-715_Test143_LFR_R3_Acceptance_Test_001]</p>
<p>LFR Software version 3.0.0.1<br />DAS Software version 2.5.3.0<br />IDB version 3.8.0</p> LFR-FSW - Bug #514 (Closed): [JIRA] (RPWMEB-276) The cause of the reset is not updated in TM_LFR_HKhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/5142015-09-28T09:45:46ZVeronique bouzid
<p>Voici le point JIRA<br />The cause of the reset is not updated in TM_LFR_HK<br />After the power on of the LFR board and the boot of the LFR S/W, HK_LFR_RESET_CAUSE is set to UNKNOWN_CAUSE.</p>
<p>The expected value is : POWER_ON.</p>
<p>DPU EM#2<br />LFR SW 2.0.0.0</p> LFR-FSW - Feature #502 (Closed): Valider le requirement SSS-CP-FS-610https://hephaistos.lpp.polytechnique.fr/redmine/issues/5022015-09-19T09:43:39ZVeronique bouzid
<p>Je rappelle le requirement qui concerne la section Cache configuration<br />The RPW Flight Software shall explicitly configure the data and instruction caches at startup.</p>
<p>--> la réponse de Paul <br />Ça peut être vérifié en lisant les registres appropriés avec SoExplorer juste après le démarrage de la carte puis après le démarrage du logiciel.</p>
<p>Après discussions avec Alexis , il manque une fonction dans socexporer pour connaitre l'etat du cache.<br />Alexis propose del'ajouter , voir projet Socexplorer <a class="issue tracker-2 status-2 priority-2 priority-default" title="Feature: Ajouter une fonction retournant l'etat du cache (In Progress)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/497">#497</a>.</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 #484 (Closed): WRONG SEQUENCE_CNT on PACKET_ID=0xccc with ASM=BP1=4shttps://hephaistos.lpp.polytechnique.fr/redmine/issues/4842015-08-13T15:43:29ZVeronique bouzid
<p>Quand en normal mode, on configure les paramètres <br />- ASM = 4s<br />- BP1 = 4s</p>
<p>On observe un dysfonctionnement dans les numéros de sequence, le SEQUENCE_CNT=1 arrive apres SEQUENCE_CNT = 4, cela n est pas grave si le TIME est respecté mais ce n 'est pas le cas.<br />15:57:56.78621, TM_LFR_SCIENCE_NORMAL_BP1_F0, <strong>TIME=0x800000118635</strong>, PACKET_ID=0xccc, <strong>SEQUENCE_CNT=0</strong><br />15:57:56.810595, TM_LFR_SCIENCE_NORMAL_ASM_F0, TIME=0x800000118635, PACKET_ID=0xccc, SEQUENCE_CNT=2<br />15:57:56.817362, TM_LFR_SCIENCE_NORMAL_ASM_F0, TIME=0x800000118635, PACKET_ID=0xccc, SEQUENCE_CNT=3<br />15:57:56.831791, TM_LFR_SCIENCE_NORMAL_ASM_F0, TIME=0x800000118635, PACKET_ID=0xccc, SEQUENCE_CNT=4<br />15:57:56.835711, TM_LFR_SCIENCE_NORMAL_BP1_F1, <strong>TIME=0x80000011863d</strong>, PACKET_ID=0xccc, <strong>SEQUENCE_CNT=1</strong><br />15:57:56.844743, TM_LFR_SCIENCE_NORMAL_ASM_F1, TIME=0x80000011863d, PACKET_ID=0xccc, SEQUENCE_CNT=5<br />15:57:56.858449, TM_LFR_SCIENCE_NORMAL_ASM_F1, TIME=0x80000011863d, PACKET_ID=0xccc, SEQUENCE_CNT=6<br />15:57:56.864549, TM_LFR_SCIENCE_NORMAL_ASM_F1, TIME=0x80000011863d, PACKET_ID=0xccc, SEQUENCE_CNT=7<br />15:57:56.869359, TM_LFR_SCIENCE_NORMAL_BP1_F2, TIME=0x800000118723, PACKET_ID=0xccc, SEQUENCE_CNT=8<br />15:57:56.879156, TM_LFR_SCIENCE_NORMAL_ASM_F2, TIME=0x800000118723, PACKET_ID=0xccc, SEQUENCE_CNT=9<br />15:57:56.884622, TM_LFR_SCIENCE_NORMAL_ASM_F2, TIME=0x800000118723, PACKET_ID=0xccc, SEQUENCE_CNT=10<br />15:57:56.889497, TM_LFR_SCIENCE_NORMAL_ASM_F2, TIME=0x800000118723, PACKET_ID=0xccc, SEQUENCE_CNT=11</p>
<p>On doit observer une incrementation de 1 dans le numero de sequence chronologiquement<br />pour tous ces produits car ils ont le meme PACKET_ID=0xccc et DESTINATION_ID=0.</p>
<p>Ce schéma se trouve durant le test.</p>
<p>Le script utilisé est /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0029/normal_mode_parameter_set.py</p>
<p>Les fichiers (2015_08_10-17_09_45-Detail.txt et 2015_08_10-17_09_45-Extract.txt) se trouvent dans le répertoire data/R3/3.0.0.8/1.1.88/SVS-0029.</p>
<p>Contexte du test<br />----------------<br />FSW 2.0.2.3<br />VHDL 1.1.88<br />Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />EM 2<br />StarDundee spacewire</p> LFR-FSW - Task #432 (Closed): Valider le signal de calibrationhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/4322015-06-09T11:26:54ZVeronique bouzid
<p>Il faudrait créer un script qui envoiela commande TC_LFR_ENABLE_CALIBRATION et 5mn plus tard envoie TC_LFR_DISABLE_CALIBRATION<br />et que l on enregistre les données produites.<br />Ces données devraient validées le signal de calibration qui est décrit dans le document dixit Paul.<br />DOnc il faut trouver ce document et rajouter dans le rapport de calibration ou bien dans la SVS comment le depuillement de ce test.</p>
<p>Aucune entrée n est à appliquer sur les sensors car le signal de calibration est interne.</p>
<p>Actuellement 3 requirements referencent la calibration<br />- SVS-0051 pas ecrit (SSS-CP-EQS-522) TC_LFR_ENABLE_CALIBRATION <br />- SVS-0052 pas ecrit (SSS-CP-EQS-523) TC_LFR_DISABLE_CALIBRATION<br />- SVS-0053 2 scripts hkCalEnabled_Step01.py et hkCalEnabled_Step02.py SSS-CP-EQS-522 + SSS-CP-EQS-524 + SSS-CP-EQS-523</p> LFR-FSW - Task #398 (New): Utilisez le script periodicity.py sur les tests de Geraldhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/3982015-04-27T13:32:54ZVeronique bouzid
<p>Il serait bien d'utiliser le script periodicity.py que Bruno a développé<br />pour dépouiller les tests de charge (analyse des fichiers de type *_packet_log.data, format ecrit par Paul).</p>
<p>Le script de Gerald verif_fields.py gere un fichier tm_time.txt dont le format<br />n'est pas trop éloigné de celui de Paul.</p>
<p>Il faudrait transformer le format<br />07:57:08.364223, TM_LFR_SCIENCE_NORMAL_BP1_F2, TIME=0x0000001133f7</p>
<p>en<br />2015 3 25 16:22:00:360 TM_LFR_SCIENCE_SBM1_BP1_F0 time = 0x 80000020 5bd2</p>
<p>J ai donc commencé par <br />1- Recuperer la date du fichier à traiter pour l'ecrire dans le fichier (verif_fields.py) + passage de l argument<br />2- reformatter les infos comme il faut (supprimer les micros secondes, parser le temps...)<br />3- creer un fichier resultat avec la nomemclature <strong><em>packet_log.data et qui ne contient que les TM</em></strong></p> LFR-FSW - Bug #185 (Closed): [JIRA] RPWMEB-275 The timecode tickout counter and the last timecode...https://hephaistos.lpp.polytechnique.fr/redmine/issues/1852014-07-18T10:27:27ZVeronique bouzid
<p>The parameters HK_LFR_DPU_SPW_TICK_OUT_CNT and HK_LFR_DPU_SPW_LAST_TIMC are not updated in the TM_LFR_HK packets.</p> LFR-FSW - Bug #184 (Closed): [JIRA] (RPWMEB-282) Generation period of TM_LFR_SCIENCE_NORMAL_CWF_F...https://hephaistos.lpp.polytechnique.fr/redmine/issues/1842014-07-18T10:18:06ZVeronique bouzid
<p>It is expected to have one TM_LFR_SCIENCE_NORMAL_CWF_F3 packet produced every 42 seconds.</p>
<p>LFR produces 4 TM_LFR_SCIENCE_NORMAL_CWF_F3 packets every 168 seconds (4 x 42 seconds), with an interval of 10 seconds between each packet.</p>
<p>Could LFR team clarify this point?</p>
<p>For the LFR TM analysis, it should be better to have one TM_LFR_SCIENCE_NORMAL_CWF_F3 packet every 42 seconds.</p>
<p>La reponse de Paul</p>
<p>This is linked to the way the hardware is performing the data acquisition in LFR. We have buffers of 2688 points inside the VHDL (this is a compromise between several constraints: the size of each individual packet requested by the DAS team, the fact that 4 different frequency snapshots are built at the same time, the fact that snapshots and continuous waveforms are built simultaneously in several modes...).<br />Once the buffer is full, an interruption request is raised and the flight software processes the buffer. The time before receiving the first packet can not be changed, it is 2688/16 for the CWF_F3 products. The time BETWEEN the packets can be changed. At the current time, it is 10s but we can increase it if is more practical for the DAS.</p>
<p>La reponse de Philippe est <strong>OK, this behavior shall be documented in the LFR S/W User Manual.</strong></p> LFR-FSW - Bug #182 (Closed): [JIRA] (RPWMEB-283) The content of the PA_LFR_ACQUISITION_TIME ...https://hephaistos.lpp.polytechnique.fr/redmine/issues/1822014-07-09T08:39:49ZVeronique bouzid
<p>Suite à la remontée par Philippe Plasson de l incident RPWMEB-283</p>
<p>J ai ecrit un test pour reproduire le bug.Ce script se nomme <strong>my_timeissue_normal.py</strong>. Il se trouve sous /home/validation.Il est en piece jointe.</p>
<p>J'ai envoyé un <strong>UPDATE_TIME</strong> avec comme temps de réference <strong>CP_RPW_TIME=0x1b45fd970000</strong><br />qui correspond au 1er juillet 2014 vers 23h10 . J ai mis le temps indiqué par Philippe sans vérifier que cela correspondait bien au 1er juillet 2014.<br />Je leur fais confiance.</p>
<p>Je vois bien la mise à l heure de LFR apres reception du time code<br />09:30:22.591245, TM_LFR_HK,TIME=0x8000000346da</p>
<p><strong>09:30:23.591236, TM_LFR_HK,TIME=0x1b45fd976093</strong></p>
<p>la premiere données scientifique qui arrive<br />09:30:23.991365, TM_LFR_SCIENCE_NORMAL_BP1_F0,*TIME=0x1b44fd97a7e4,PA_LFR_ACQUISITION_TIME=0x1b44fd97a7e4*</p>
<p><strong>et la BINGO, on voit 0x1b44 au lieu de 0x1b45</strong>*
*<br />idem pour toutes le TM</p>
<p>09:35:26.392595, TM_LFR_SCIENCE_NORMAL_SWF_F0, TIME=0x9b44febfa146,PA_LFR_ACQUISITION_TIME=0x9b44febfa146<br />09:35:28.59267, TM_LFR_SCIENCE_NORMAL_SWF_F1,TIME=0x9b44febf6c3e,PA_LFR_ACQUISITION_TIME=0x9b44febf6c3e</p>
<p>--------------------------------------------------------------------------------------<br />Contexte:</p>
<p>SocExplorerEngine.getSocExplorer: Version = 0.2.2, Branch = default, Changeset = c839740ef520<br />Carte EM<br />Vhdl: 1.1.23<br />Soft: 2.0.0.0 <br />Brique Star-Dundee S/N 46120065.</p>
<p>script: /home/validation/my_timeissue.py</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue3_rev0</p>