LFR-FSW: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012023-06-14T15:32:11ZRedmine
Redmine Task #4115 (In Progress): Mise à jour DP R3.3 suite à émission des RIDS par le CNEShttps://hephaistos.lpp.polytechnique.fr/redmine/issues/41152023-06-14T15:32:11Zbruno katra
<p>Mail Dixon du 13/06/2023</p>
<p>Bonjour,</p>
<p>Vous trouverez en PJ mes FEPS.</p>
<p>Il y a pas mal de remarques (dont des coquilles).<br />On peut prévoir un point ensemble pour les parcourir et bien identifier les problèmes "réels".</p>
<p>Bonne journée,</p>
<p>Charles.</p>
<p>(fichier excel attaché)</p>
<hr />
<p>Fichiers mis à jour pour relivraison :</p>
<p>- SCF (00037) (pas de chgt de version) --> DP mis à jour<br />- SPAMR (00036) (pas de chgt de version) --> DP mis à jour<br />- SPC 00276 (pas de chgt de version) --> DP mis à jour<br />- SGSE CDL (00205) (pas de chgt de version) --> DP mis à jour<br />- spec LFR (00003) (pas de chgt de version) --> DP mis à jour<br />- SRS (pas de chgt de version) --> DP mis à jour<br />- SPC-277 (pas de chgt de version) --> DP mis à jour<br />- SDD (00039) (pas de chgt de version) --> DP mis à jour<br />- NTT-271 (pas de chgt de version) --> DP mis à jour<br />- SUM-123 (pas de chgt de version) --> DP mis à jour<br />- RPT-199 (pas de chgt de version) --> DP mis à jour<br />- RPT-168 (pas de chgt de version) --> DP mis à jour<br />- RPT- 95 (pas de chgt de version) --> DP mis à jour<br />- NTT124 (pas de chgt de version) --> DP mis à jour<br />- SVS-00066 (pas de chgt de version) --> DP mis à jour<br />- CPS (00191) --> DP mis à jour<br />- document de Thomas RPW-MEB-LFR-SPC-00275 --> DP mis à jour</p> Task #3991 (In Progress): Mise en place d'un protocole de test pour la validation de la correctio...https://hephaistos.lpp.polytechnique.fr/redmine/issues/39912022-10-21T11:47:10Zbruno katra
<p>Le bug est détaillé là : <a class="issue tracker-1 status-3 priority-2 priority-default" title="Bug: Moyennage des SM erroné pour F0 et F1 dans FSW <=3.2.0.24 (Resolved)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/3821">#3821</a></p>
<p>VALIDATION : j'ai créé points à points des signaux personnalisés qui sont ensuite générés par les ANALOG DISCOVERY. En utilisant les scripts pour la validation de PAS : ces signaux sont triggés de façon à être synchrones avec l'acquisition des ASM. Je génére ainsi des +/- courtes impulsions à une fréquence définie que je peux faire coïncider temporellement avec une ou plusieurs des 8 SM calculés à bord.</p>
<p>En comparant ensuite 3.2.0.24 VS 3.3.0.x : on peut caractériser si toutes les SM sont bien prises en compte ou bien seulement la première comme avant.</p> Bug #3936 (In Progress): Comparaison/validation FSW 3.2.0.24 vs 3.3.0.7 avec matrices unitaires.https://hephaistos.lpp.polytechnique.fr/redmine/issues/39362022-03-15T14:56:30Zbruno katra
<p>En relation avec <a class="issue tracker-4 status-2 priority-2 priority-default" title="Task: Matrices de passage par défaut pour les ASM : à valider (In Progress)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/3877">#3877</a> il est pertinent de vérifier la cohérence entre 3.2.0.24 vs (3.3.0.7 avec matrices unitaires). Les comportements attendus doivent être similaires entre les 2 (à la différence près de la correction de la moyenne des ASM qui ne doit pas trop se voir dans le cadre de signaux constants).</p>
<p>J'ai rejoué les runs PREL-08 ( <a class="issue tracker-4 status-2 priority-2 priority-default" title="Task: Matrices de passage par défaut pour les ASM : à valider (In Progress)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/3877">#3877</a> ) mais en 3.2.0.24, les datadumps sont ici :<br /><a class="external" href="https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.2.0.24/PREL-09&fileid=2507041">https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.2.0.24/PREL-09&fileid=2507041</a></p> Task #3897 (In Progress): Faire un test avec les matrices de chgt de repère/calibration mises à ...https://hephaistos.lpp.polytechnique.fr/redmine/issues/38972021-11-18T08:32:29Zbruno katra
<p>Afin de valider la non régression au niveau des signaux (amplitude et forme).<br />Thomas a envoyé le tableau 32x36</p> Task #3877 (In Progress): Matrices de passage par défaut pour les ASM : à valider https://hephaistos.lpp.polytechnique.fr/redmine/issues/38772021-09-17T09:52:23Zbruno katra
<p>Oui c'est exactement ça, dans le dernier où avant dernier commit tu trouveras les matrices par défaut générées avec les valeurs de Thomas.</p>
<p>Envoyé depuis mon smartphone Xperia de Sony</p>
<p>---- Bruno KATRA a écrit ----</p>
<p>Salut Alexis et Thomas.</p>
<p>J'ai pensé à un truc : qu'en est-il des KCOEFF par défaut au démarrage</p>
<p>de LFR?</p>
<p>De mémoire, avec l'ancienne implé : tous les coeff étaient à 1.0 au</p>
<p>démarrage.</p>
<p>Mais maintenant que les KCOEFF ne sont plus des KCOEFF mais les</p>
<p>paramètres permettant de calculer les matrices de passage pour les ASM,</p>
<p>je suppose qu'il existe des matrices par défaut au démarrage de LFR et</p>
<p>que donc les KCOEFF par défaut ne sont pas des 1.0 mais bien des valeurs</p>
<p>différentes?</p>
<p>Merci</p>
<p>-------------------------------------------------------------<br />Mapping Discospace :</p>
<p>Analog Discovery 1 : E1/E2<br />Analog Discovery 2 : B1/B2<br />Analog Discovery 3 : B3<br />-------------------------------------------------------------</p> Bug #3851 (Feedback): bruit périodique à F1 vu sur les BPs et ASM mais pas sur les SWFhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/38512021-05-25T09:11:43Zthomas chust
<p>Un truc bizarre/paradoxal depuis le début de la mission: on observe sur les produits spectraux à F1 (BP2, BP1 et ASM) un bruit large bande qui module régulièrement en intensité sur une période de ~3h. Parfois cette modulation est accentuée soudainement une ou deux fois puis retour à la "normale". Alors que sur les produits SWF il n'y a rien à voir (semble-t-il) ?</p>
<p>1) Exemples des 18 et 19 mai 2020 (on voit l'accentuation le 18 mai associée à une hausse du bruit global visible sur les SWF mais sans modulation)</p>
<p>2) Exemple du 7 février 2021 (ASM toutes les 52 s et SWF toutes les 30 s)</p>
<p>Il faudrait que j'intègre sur les fréquences les SWF pour obtenir la même résolution en fréquences que les BP pour être sûr que cette modulation n'est pas cachée dans les SWF. Mais j'y crois pas ... Du coup il y a peut-être quelque chose à voir du coté du FSW dans sa façon de faire les moyennes ?</p> Bug #3821 (Resolved): Moyennage des SM erroné pour F0 et F1 dans FSW <=3.2.0.24https://hephaistos.lpp.polytechnique.fr/redmine/issues/38212021-03-29T09:26:52Zbruno katra
<p>Pour F0 et F1, on moyenne 8 SM pour faire une ASM. La boucle est fausse : Seul la première SM est comptabilisée et moyennée (*8/8).</p>
<p><a class="external" href="https://github.com/LaboratoryOfPlasmaPhysics/LFR_Flight_Software/blame/729417ab5a3e7e5854a6665a3662e2b8ebc7756e/header/processing/fsw_processing.h#L206">https://github.com/LaboratoryOfPlasmaPhysics/LFR_Flight_Software/blame/729417ab5a3e7e5854a6665a3662e2b8ebc7756e/header/processing/fsw_processing.h#L206</a></p>
<p>Message de Alexis :<br /><pre>
"Ce qui me choque dans la ligne en question, c'est qu'on a une boucle
sur k et qu'on somme N fois la même composante de la même matrice selon
que incomingSMIsValid[k] == MATRIX_IS_NOT_POLLUTED.
Je trouve ça étrange."
</pre></p> Support #1091 (Feedback): Lost some BP packets in BURST modehttps://hephaistos.lpp.polytechnique.fr/redmine/issues/10912017-04-27T09:51:05ZVeronique bouzid
<p>1 test "CAS NOMINAL" <br />on entre en burst mode<br />17:34:51.300563, TC_LFR_ENTER_MODE (CP_LFR_MODE=2)<br />17:34:52.481738, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x27b7f503ffff<br />17:34:52.537164, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x27b7f504000a</p>
<p>17:34:53.482246, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x27b7f5050000<br />17:34:53.537797, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x27b7f505000a</p>
<p>17:34:54.482316, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x27b7f5060000<br />17:34:54.537483, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x27b7f506000a</p>
<p>17:34:55.481104, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x27b7f5070000<br />17:34:55.534692, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x27b7f507000b</p>
<p>17:34:56.486681, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x44a32a03c608<br />17:34:56.489927, TM_LFR_SCIENCE_BURST_BP2_F0, TIME=0x44a32a03c608</p>
<p>17:34:56.527804, TC_LFR_ENTER_MODE (CP_LFR_MODE=3)<br />17:34:56.548004, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x44a32a03c612<br />17:34:56.587099, TM_LFR_SCIENCE_BURST_BP2_F1, TIME=0x44a32a03c612<br />17:34:56.587799, TM_LFR_TC_EXE_SUCCESS, TIME=0x44a32a04efa2</p>
<p>17:34:56.920005, TM_LFR_SCIENCE_SBM1_BP1_F0, TIME=0x44a32a050001</p>
<p>Ce cas est nominal. On recoit bien tous les produits BURST meme apres le passage en SBM1.<br />5 BURST_BP1_F0<br />5 BURST_BP1_F1<br />1 BURST_BP2_F0<br />1 BURST_BP2_F1</p>
<p>-Le meme test rejoué " ERREUR" <br />16:27:43.862845, TC_LFR_ENTER_MODE (CP_LFR_MODE=2)<br />16:27:43.871156, TM_LFR_TC_EXE_SUCCESS, TIME=0x318b8203e9a3</p>
<p>16:27:45.049608, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x318b82040001<br />16:27:45.105166, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x318b8204000b</p>
<p>16:27:46.050847, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x318b82050001<br />16:27:46.106364, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x318b8205000b</p>
<p>16:27:47.049695, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x318b82060001<br />16:27:47.104954, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x318b8206000c</p>
<p>16:27:48.049311, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x318b82070001<br />16:27:48.103473, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x318b8207000c</p>
<p>16:27:49.055988, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x3d633003c8cd<br />16:27:49.058668, TM_LFR_SCIENCE_BURST_BP2_F0, TIME=0x3d633003c8cd</p>
<p>16:27:49.084134, TC_LFR_ENTER_MODE (CP_LFR_MODE=3)<br />16:27:49.094502, TM_LFR_TC_EXE_SUCCESS, TIME=0x3d633004ebbe<br />16:27:49.476704, TM_LFR_SCIENCE_SBM1_BP1_F0, TIME=0x3d6330050000</p>
<p>--> la il nous manque BURST_BP1_F1 et un BURST_BP2_F1 un on a seulement recu<br />5 BURST_BP1_F0<br />4 BURST_BP1_F1<br />1 BURST_BP2_F0</p>
<p>Ma piste s oriente vers le changement de mode qui resette les buffers alors parfois les produits burst sont deja dabns la file d attente pour envoi et parfois<br />non</p>
<p>--> Peux-tu expliquer ?</p>
<p>J ai rencontré plusieurs ce petit dysfonctionnement souvent sur le burst mais egalement sur les NORMAL_BP NORMAL_ASM et sur les BP en SBM2.</p>
<p>Je ne classe pas cette issue en BUG car je pense que c'est le comportement de LFR et qu il faut juste documenter ce point.</p>
<p>Contexte du test<br />----------------<br />FSW 3.2.0.15<br />VHDL 3.1.91<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = default, Changeset = c459540a6dbdcbb4e17f204685fce02c070ba971+<br />EQM sans Timegen<br />StarDundee</p> Support #1090 (Feedback): Back to time managementhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/10902017-04-27T07:43:37ZVeronique bouzid
<p>Premier cas de test<br />- LFR a booté, <br />Le soft remonte bien que le timecode est missing et la derniere erreur tracée est coherente avec cela<br />HK_LFR_UPDATE_TIME_TC_CNT=0, HK_LFR_LE_CNT=1, HK_LFR_ME_CNT=0, HK_LFR_HE_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIMEC = 42129, HK_LFR_LAST_ER_CODE: MISSING = 21, HK_LFR_LAST_ER_TIME=0x8000000209dd, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, , HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=1, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0,</p>
<p>- Envoi d'une TC_LFR_UPDATE_TIME avec 300ms apres une timecode invalid ( je mets 5)<br />TC_LFR_UPDATE_TIME, CCSDS_VERSION, CP_RPW_TIME=0x38f223010000</p>
<p>sur la TM_LFR_HK<br />HK_LFR_UPDATE_TIME_TC_CNT=1, HK_LFR_LE_CNT=1, HK_LFR_ME_CNT=0, HK_LFR_HE_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIMEC = 42129, HK_LFR_LAST_ER_CODE: MISSING = 21, HK_LFR_LAST_ER_TIME=0x8000000209dd, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=1, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0,</p>
<p>--> Le soft ne remonte aucune erreur et donc la derniere erreur tracée est toujours missing.</p>
<p>--> Peux-tu expliquer CELA</p>
<p>Contexte du test<br />---------------------<br />FSW 3.2.0.15<br />VHDL 3.1.91<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = default, Changeset = c459540a6dbdcbb4e17f204685fce02c070ba971+<br />EQM sans Timegen<br />StarDundee</p> Task #697 (New): LFR technical specification updates related to FSW-R3+https://hephaistos.lpp.polytechnique.fr/redmine/issues/6972016-05-26T12:43:44ZAlexis Jeandet
<p>Les exigences décrivant les matrices spectrales et les BPs de LFR devraient être mises à jour dans la Spécification Technique LFR.<br />Voir à partir de la REQ-RPW-LFR-2405. Je me demande même dans quelle mesure il ne faudrait pas ajouter une ou deux exigences sur les masques vu que les traitements sont détaillés sinon la spec est fausse.</p> Feature #593 (In Progress): adapter tm_lfr_period.py au fonctionnement des modeshttps://hephaistos.lpp.polytechnique.fr/redmine/issues/5932016-01-26T08:29:15ZVeronique bouzid
<p>Le normal mode ne s'interrompant plus quand on commute vers sbm1 et sbm2, il faut modifier <br />la fonction tm_lfr_period.py qui testait le timing en fonction du mode actif.</p>
<p>Maintenant la prise en compte des TM_LFR_SCIENCE_NORMAL* doit etre global pour vérifier la continuté des timing.</p> 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> Task #492 (New): Implementation Timing LFRhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/4922015-09-10T12:32:30ZVeronique bouzid
<p>Ces informations sont extraites du document RPW-SYS-SSS-00013-LES_Issue3_rev3_Software_System_Specification_bars.pdf</p>
<p>1- Liste des requirements liés au Timing (section Time management 4.1.4)</p>
<p>SSS-CP-FS-340 REQ-LFR-SRS-5300 SVS-0020<br />SSS-CP-FS-350 REQ-LFR-SRS-5217 Design<br />SSS-CP-FS-360 REQ-LFR-SRS-5218 SVS-0011<br />SSS-CP-FS-370 REQ-LFR-SRS-5219 SVS-0012<br />SSS-CP-FS-376 REQ-LFR-SRS-5237 noté Design mais on a un test<br />SSS-CP-FS-380 REQ-LFR-SRS-5220 SVS-0013<br />SSS-CP-FS-390 REQ-LFR-SRS-5301 Design<br />SSS-CP-FS-400 REQ-LFR-SRS-5221 Design<br />SSS-CP-FS-405 REQ-LFR-SRS-5238 SVS-0014<br />SSS-CP-FS-410 REQ-LFR-SRS-5222 SVS-0076</p>
<p>Résumé de ma compréhension du timing LFR</p>
<p>le développement du software est axé principalement sur le fonctionnement nominal :<br />- toutes les secondes, LFR recoit du DAS le couple suivant<br /> - une commande TC_LFR_UPDATE_TIME ( CTR Time Update command ou bien CTR SpaceWire command packet)<br /> - 300ms aprés un timecode valide (SpaceWire time code)</p> Bug #383 (Feedback): petite irrégularité de temps pour les CWF à F1 ?https://hephaistos.lpp.polytechnique.fr/redmine/issues/3832015-04-13T08:54:29Zthomas chust
<p>Point similaire au point <a class="issue tracker-1 status-3 priority-2 priority-default" title="Bug: petite irrégularité de temps pour les CWF à F2 ? (Resolved)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/382">#382</a> mais avec les CWF à F1:</p>
<p>Le cas considéré ici est un ctc-5: balayage en fréquence où on enregistre 104 fichiers CWF à F1 comprenants chacun 320 paquets de 336 échantillons. Voir les fichiers joints.</p>
<p>Avec la configuation FSW = 2.0.2.3 et VHDL = 1.1.68 on observe:<br />- les temps des paquets de 336 échantillons sont bien séparés de 5376 2^-16 s [336 / 4096 / 2^-16] à 2^-16 s près,<br />- SAUF de temps à autre entre des paquets p et p+1 où l'on observe la valeur de 5474 et où l'entier p a la caractéristique d'être un multiple de 8.</p>
<p><strong>Conclusion: la datation des premiers paquets de chaque buffer (2688=8*336) est de temps à autre légèrement erronée, de l'ordre de 2 fine times (~ 30 micro secondes) ?</strong></p> Bug #382 (Resolved): petite irrégularité de temps pour les CWF à F2 ?https://hephaistos.lpp.polytechnique.fr/redmine/issues/3822015-04-10T22:39:06Zthomas chust
<p>Des tests ont été fait avec pas mal de fichiers durant les procédures automatiques de calibration/étalonnage.<br />Le cas considéré ici est un ctc-6: balayage en fréquence où on enregistre 96 fichiers CWF à F2 comprenants chacun 24 paquets de 336 échantillons. Voir les fichiers joints.</p>
<p>Avec la configuation FSW = 2.0.2.3 et VHDL = 1.1.68 on observe:<br />- les temps des paquets de 336 échantillons sont bien séparés de 86016 2^-16 s [336 / 256/ 2^-16] à 2^-16 s près<br />- SAUF entre le 8ème et 9ème paquet où on observe des valeurs allant de 86003 à 86006 fine times,<br />- et SAUF entre le 16ème et le 17ème paquet où on observe la même irrégularité.</p>
<p>Si j'ai bien compris, 8 paquets correspond à un buffer plein (2688=8*336), et <strong>il semblerait que la datation du premier paquet de chaque buffer est légèrement erroné, de l'ordre de 10 fine times (~ 150 micro secondes) ?</strong></p>