Status #NectarCAMX
#NectarCAM: (no topic set)
[12:42] == Dirk_ [869e10a4@gateway/web/freenode/ip.134.158.16.164] has joined #NectarCAM
[12:44] == Dirk4test [869e10a4@gateway/web/freenode/ip.134.158.16.164] has quit [Ping timeout: 252 seconds]
[12:44] <Dirk_> @PatrickS J'installe "xterm" pour avoir un client "lightweight" qui peut me renvoyer le ZFitsWriter dans un coin.
[12:51] == FT_ [869e99db@gateway/web/freenode/ip.134.158.153.219] has joined #NectarCAM
[13:04] == FT_ [869e99db@gateway/web/freenode/ip.134.158.153.219] has quit [Quit: Page closed]
[13:19] == FT_ [869e99db@gateway/web/freenode/ip.134.158.153.219] has joined #NectarCAM
[13:37] <Dirk_> Je suis de retour. L'un de vous s'est occupé du S60 pour changer la MTU ? Sinon, j'y vais.
[13:38] <Dirk_> Je crois que FT_, c'est François qui nous a rejoint.
[13:45] <Dirk_> Mes ssh vers sedipcc127 se plantent après quelques minutes d'inactivité. Vous avez observé la même chose ?
[13:57] <sizun> Ce ne serait pas plutôt la connection avec daplxa?
[14:03] <sizun> Pour le S60, je ne maitrise pas encore assez les commandes de config pour changer le MTU
[14:11] <Dirk_> Oui, soit daplxa, soit sedipcc127. L'un des deux bloque.
[14:14] <sizun> On recommence?
[14:15] <Dirk_> Pour le S60, vous avez utilisé quelle connexion ? Au CPPM, nous avons minicom et /dev/ttyS, mais cela ne semble pas être préconfiguré.
[14:16] <Dirk_> Je change le /etc/minirc.minicoms60 en minirc.S60, et on pourra utiliser "minicom S60" our accéder le S60 à travers le port USB/série.
[14:16] == sizun [84a624fc@gateway/web/freenode/ip.132.166.36.252] has quit [Quit: Page closed]
[14:16] == sizun [84a624fc@gateway/web/freenode/ip.132.166.36.252] has joined #NectarCAM
[14:17] <sizun> S60: /dev/ttyUSB0
[14:18] <Dirk_> Oui, ttyUSB0 ! (ttyUSB? chez nous pour les 6)
[14:19] <Dirk_> On dirait que le S60 répond aux requêtes DHCP aussi. Faut qu'on s'en charge aussi. (Je note.)
[14:21] <Dirk_> @Patrick, tu as pu savoir, si le numéro du 1er événement est 0 ou 1 ?
[14:22] <sizun> Non, je peux faire un run pour voir
[14:25] <Dirk_> Oui, je crois qu'on a le temps. Je ne peux pas interférer en étant sur le S60 ; je ne risque pas d'interférer, parce que je suis sur le FTOS qui est indépendant du routage des paquets.
[14:26] <sizun> Je viens de faire un run en sauvegrdant les données au format qNectarCam et le premier évènement sauvé est:
[14:26] <sizun> 1450272229223 ;1;0;1;0;0 ;10707;29803;7720;33432;12468;33566;10537;31480;13161;0;15239;35108;11071;34845 ;237;220;273;329;227;211;264;257;217;228;273;277;267;299;209;314;235;207;288;496;617;702;715;603;40 5;290;225;195;179;257;258;383;298;252;256;151;114;206;126;132;141;76;185;173;129;78;148;151;121;108;175;161;989;2980;4071;4095;4095;4067;2775;1141;57;0;0;0;885;954;761;302;157;168;150;128;130;164;183;195;180;193 ;184;168;136;199;2
[14:26] <sizun> Il est donc possible qu'il ait l'eventID 1
[14:28] <houles> je ne comprends ce que ça veut dire
[14:28] <houles> ce que tu as copié
[14:29] <houles> patrick
[14:29] <sizun> Le run a produit 3 fichiers, 1 par FEB
[14:29] <sizun> 3febs__drawer1_151216132340_0.dat, 3febs__drawer2_151216132340_0.dat, 3febs__drawer3_151216132340_0.dat
[14:30] <sizun> J'ai copié la première "vraie" ligne du premier fichier,
[14:30] <houles> mais quel est le format ?
[14:30] <sizun> qui contient les données du 1er évènement du 1er drawer
[14:32] <houles> mais quel est le format ?
[14:33] <sizun> Cela commence par timestamp; eventID
[14:33] <houles> donc event
[14:33] <houles> id = 1
[14:33] <sizun> Oui, je pense
[14:33] <houles> il faudrait voir avec wireshark
[14:34] <sizun> OK, je vais essayer.. mais cela n'est pas forcément facile de capturer le bon paquet avec wireshark
[14:34] <houles> c'est juste après l'adresse IP 01000a0a sur 32 bit
[14:34] <houles> dans la paylod
[14:34] <houles> payload = data dans wireshark
[14:35] <Dirk_> Oui, je crois que nous ne pouvons pas être sûrs quand Vincent a traduit en 32 ou 16 bits. Le premier nombre semble être 32bits, alors que les 227, 211, 264 etc. devraient être des piedestaux endu 16bits.
[14:35] <Dirk_> Tu peux indiquer un filtre (en haut à gauche, je crois) dans wireshark. Il te permet une sorte d'auto-complete.
[14:35] <Dirk_> ip src = 10.10.0.1 devrait t'afficher uniquement les paquets venant de cette carte. (Réduis le taux de trigger au min. !)
[14:36] <houles> pas besoin de filtre à 300 Hz
[14:36] <Dirk_> Tous les ports du S60 sont en MTU=4096 maintenant. Cela devrait aller jusqu'à 120 samples ! :-)
[14:36] <Dirk_> @Julien Oui, mais il doit capter le tout premier paquet.
[14:36] <houles> netmap ne pourrra gerer un mtu jusquà 2048
[14:37] <houles> (j'espère)
[14:37] <houles> jamais essayé
[14:37] <Dirk_> Le S60 sera plus fort que netmap alors :-)
[14:39] <sizun> aaaaaaaae6ee000001000a0a01000000000001000000000000000000212aed6e771e29807f30707f21292c77f1320000683b9a86f72aa087800078003900ac00990074004a0093008a006b004200a70075005400b6004c004f005e001b021d08e80eff0fff0fff0f240c8705df000000000000000c024d04f30291016b01a700830097000701fc00d900e30015011d0115012501e0003401ee00dc0016015101c900c8009b00030155011c02c30209039d02f4017901bb00d7008e00ad002f01940117010001f9001a01150100010e010e015d01e900f800f90
[14:39] <houles> ça commence donc bien à 1
[14:40] <sizun> OK. On fait un run avec nf="48"? puis nf="60"?
[14:41] <Dirk_> Et selon le "format VV" 1450272229223=0x151aaf60767
[14:41] <Dirk_> Bon, @Julien, tu dois modifier le code pour commencer à 1 ?
[14:42] <houles> dirk, il faudra remonter à patrick N qu'il faut commencer à compter à 0
[14:42] <Dirk_> NB : Les numéros d'événements ProtoBuf sont des numéros de série (pour le moment).
[14:44] <houles> dirk, il faudrait que tu fasses un svn update au moins pour eventProcessing.c
[14:44] <Dirk_> OK, on reste sur un début à 0 pour EVB et 1 pour FEB ?
[14:50] <Dirk_> Donc, on passe en nf=48 dans un premier temps.
[14:51] <sizun> OK
[14:55] <Dirk_> Nous avons un problème avec netmap / device not found.
[14:58] <Dirk_> C'est bon ; le défaut au CPPM (et dans SVN) est : 4 interfaces 10Gbps.
[14:58] <Dirk_> Ready to go.
[14:58] <Dirk_> START
[14:59] <sizun> Started
[14:59] <Dirk_> Parfait. Merci. STOP
[14:59] <sizun> Stopped
[15:00] <Dirk_> Au fait, pourquoi nf=48 ?
[15:00] <Dirk_> Le fichier est Run003... ; on regarde de notre côté.
[15:02] <Dirk_> Au fait, Julien avait vu pendant la pause de midi que les valeurs sont bien HiGain(nf fois), puis LoGain(nf fois). Donc, la description dans le fichier ZFITS est bonne, contrairement à ce qu'on croyait avant midi.
[15:04] == sizun_ [84a624fc@gateway/web/freenode/ip.132.166.36.252] has joined #NectarCAM
[15:05] == sizun [84a624fc@gateway/web/freenode/ip.132.166.36.252] has quit [Ping timeout: 252 seconds]
[15:05] <Dirk_> Résultat : Il reste toujours des zéros dans le fichier.
[15:06] <sizun_> J'ai peut-être manqué certains de vos messages, mon client IRC avait l'air gelé
[15:07] <Dirk_> Oui, je te renvoie :-)
[15:07] <Dirk_> Au fait, pourquoi nf=48 ?
[15:08] <Dirk_> Le fichier est Run003... ; on regarde de notre côté. Résultat : Il reste toujours des zéros dans le fichier.
[15:08] <Dirk_> Au fait, Julien avait vu pendant la pause de midi que les valeurs sont bien HiGain(nf fois), puis LoGain(nf fois). Donc, la description dans le fichier ZFITS est bonne, contrairement à ce qu'on croyait avant midi.
[15:08] <Dirk_> Par contre (@FT_, si tu écoutes ?) dans la doc de PatrickN, il dit qu'il commence avec les loGain, alors que c'est clairement des hiGain, puisqu'ils saturent à 4095, et les autres sont plus petits.
[15:11] <sizun_> Je teste nf="40"
[15:11] <Dirk_> Je ne comprends pas. Pourquoi 40 ?
[15:11] <Dirk_> Et pourquoi 48 avant ?
[15:11] <Dirk_> On veut du 60 :-)
[15:12] <sizun_> nf="40" fonctionne
[15:12] <sizun_> Cela sert-t-il à quelque chose de tester nf="60"
[15:12] <sizun_> si nf="48" pose déjà problème
[15:12] <Dirk_> Julien confirme que les zéros dans le fichier (Pxl5, hiGain, carte 0.1) correspondent bien au contenu d'un paquet qu'il avait enregistré avec toi il y a quelques jours.
[15:13] <sizun_> Je ne comprend pas; ces zeros correspondent à des évènements complets?
[15:14] <Dirk_> Non, pas de problème. Nous avions les 0 au même endroit (Pxl5, hiGain, carte 0.1).
[15:14] <Dirk_> On ne peut pas dire a priori, si l'événement est complet (sauf que l'EVB l'indique), puisque tout est remis à zéro.
[15:14] <Dirk_> Mais c'est uniquement les hiGain qui sont =0. Les loGain sont bons.
[15:15] <Dirk_> Est-ce que tu vois le Pxl5, hiGain, carte 0.1 avec qNectarCam ?
[15:18] <Dirk_> sudo ip link set dev p5p1 mtu 2048
[15:18] <Dirk_> sudo ip link set dev <ICI_LE_DEV_SUR_TON_PC> mtu 2048
[15:28] <sizun_> Un MTU de 2048 sur irfulx252 ne suffit pas à fonctionner à nf="48"
[15:28] <sizun_> Peut-être dû au switch de slow control situé entre irfulx252 et le S60
[15:29] <sizun_> Par contre un run à nf="40" confirme avec qNectarCam quelque chose de bizarre avec le 5e pixel de la 1ere carte pour le haut gain
[15:29] <Dirk_> Argh. J'avais oublié qu'il y a un switch, en effet. Je croyais que le 2e PC est sur le S60 directement. (D'ailleurs, cela devrait le faire.)
[15:30] <Dirk_> Par contre, nous avons bien ce problème (Pxl5.hiGain à 0) dans le fichier 30ns aussi (Run001). Donc, tu devrais pouvoir le reproduire avec nf=30 ou même moins !
[15:32] <Dirk_> OK ?
[15:33] <sizun_> Je suppose. Mais pour le moment on continue à nf="60"?
[15:36] <Dirk_> Comme tu veux. J'aurais bien aimé confirmer ce canal en panne. Mais faisons le nf=60 d'abord, si tu préfères. Je change la config.
[15:38] <Dirk_> PREPARE :-)
[15:38] <Dirk_> START
[15:39] <sizun_> 1s
[15:40] <sizun_> Starting...
[15:40] <sizun_> Started
[15:41] <sizun_> Ca marche?
[15:42] <Dirk_> Non, aucun événement n'arrive sur l'EVB !
[15:43] <sizun_> Quelle est la taille des paquets avec nf="60"?
[15:43] <FT_> FEB number de la premiere carte
[15:43] <FT_> ?
[15:44] <sizun_> 7762
[15:46] <Dirk_> Taille : inboundDrawerPacketSize = 1530, en-tête comprise
[15:46] <Dirk_> Tu vois quelque chose arriver sur wireshark ?
[15:46] <sizun_> Je regarde
[15:49] <Dirk_> Dans https://forge.in2p3.fr/projects/nectarcam/wiki/Second_FEB_for_IRFU (La première est la deuxième, en fait ;-), c'est mélangé : 7762 et 7765.
[15:49] <FT_> Etait correcte lors des tests, curieux qu'il n'y ait que des zeros, pas commun pour une voie defectueuse !
[15:50] <sizun_> aaaaaaaae6ee000001000a0a7b8342000000617c0000000000000000d843c580742f2c9abf4e3f987042528a6d5400006362a8a9324694ab94008b0091005700c100a50079004b00a300960079005300b80089007000c3006e007e0075007803410acf0fff0fff0fe20f9a0a510433000000000000005f0311049c026302320193008a001201a8004f007700c000b9009d006d00d0009d007200d000840090009300a5005400b800aa007a004900a400a4008d006a00c500ab00d6000501fb00d700de000e0115010d012601de002c01f300e50024014701e5
[15:51] <Dirk_> C'est quoi, ces 215 octets ?
[15:52] <sizun_> La payload d'un paquet vu par wireshark
[15:52] <Dirk_> @FT, j'ai bien compris : Tu as remis toutes les lignes à la masse pour ce canal, pour vérifier qu'on n'invente pas les données dans le fichier FITS !
[15:53] <Dirk_> @Patrick, il doit y avoir plus de 215 octets. Ce n'est que le début du paquet. Mais ce qui est plus inquiétant, c'est qu'aucun paquet n'arrive à l'EVB.
[15:53] <Dirk_> On est près de la limite, où il faudrait aller sur place, mais encore deux ou trois questions pour voir, si ce n'est pas une erreur de config.
[15:54] <Dirk_> @Patrick, quand tu captes ce paquet dans WS, est-ce qu'il a la bonne taille (1530) ?
[15:55] <sizun_> wireshark indique 1852 octets
[15:55] <sizun_> + 42
[15:55] <Dirk_> Intéressant aussi. Julien a perdu 322 octets dans son calcul.
[15:57] <Dirk_> Voyons, si le problème apparaît déjà à, disons 54 samples ?
[15:58] <sizun_> OK
[15:59] <Dirk_> PREPARE
[15:59] <sizun_> Suis prêt
[15:59] <Dirk_> Oui, il y a forcement un problème. "Julien" (EVB) dit toujours : inboundDrawerPacketSize = 1530
[15:59] <Dirk_> Je ne sais pas, si il jette les paquets à taille supérieure à cette valeur nominale.
[16:00] <Dirk_> START(nf=54)
[16:00] <sizun_> Started
[16:00] <Dirk_> Toujours rien.
[16:00] <Dirk_> STOP
[16:00] <sizun_> Stopped.
[16:00] <sizun_> J'interroge wireshark?
[16:01] <Dirk_> Attends, j'ai une idée de problème.
[16:01] <Dirk_> PREPARE(nf=54) ?
[16:02] <sizun_> Quand tu veux
[16:03] <Dirk_> inboundDrawerPacketSize = 1726 ; je dois compiler le fichier de config !
[16:03] <Dirk_> START
[16:04] <sizun_> Started
[16:04] <Dirk_> STOP
[16:04] <sizun_> Done
[16:04] <Dirk_> 23246 événements reçus !
[16:05] <Dirk_> PREPARE(nf=60) ?
[16:05] <sizun_> OK
[16:05] <Dirk_> Fichier pour nf=54 : /data/NectarCAM/ZFITS/20151216/Run004_54ns.fits.fz
[16:06] <Dirk_> START
[16:06] <Dirk_> J'ai inboundDrawerPacketSize = 1894. Cela correspond à "tes" 1852+42 plus haut !
[16:07] <sizun_> OK. Starting...
[16:07] <Dirk_> J'avais bêtement oublié de compiler la config.
[16:07] <Dirk_> STOP
[16:07] <sizun_> Started
[16:07] <sizun_> Stopped
[16:07] <Dirk_> 22502 événements.
[16:07] <sizun_> On recommence?
[16:08] <Dirk_> Avec un taux plus élevé par exemple ?
[16:08] <Dirk_> fichier pour nf=60 : /data/NectarCAM/ZFITS/20151216/Run005_60ns.fits.fz
[16:09] <sizun_> François m'a envoyé une suggestion de config pour résoudre le problèm du 5e pixel
[16:09] <sizun_> Il me faut une minute pour l'appliquer
[16:09] <Dirk_> Ah, réparons donc la carte FEB. Je vais prendre ma pause clope aussi :-)
[16:12] <Dirk_> PREPARE(nf=60)
[16:14] <sizun_> Ready to start
[16:15] <Dirk_> START
[16:15] <sizun_> Started
[16:15] <Dirk_> STOP
[16:15] <sizun_> Stopped
[16:15] <Dirk_> Tu avais choisi quelle fréquence ?
[16:15] <sizun_> 30 kHz
[16:16] <Dirk_> 87609 événements
[16:16] <Dirk_> 30 kHz :-)
[16:16] <sizun_> Pas de paquets perdus/évènements incomplets?
[16:17] <Dirk_> 1243.22evts/s
[16:17] <Dirk_> Nb packets missing            = 3
[16:17] <Dirk_> Nb complete events            = 87609 Nb incomplete events          = 1
[16:18] <Dirk_> Julien rappelle : 3pq / 1evt correspondent à l'événement 0 (que les FEB n'envoient pas) !
[16:18] <Dirk_> Donc zéro paquets perdus.
[16:18] <sizun_> Great
[16:18] <Dirk_> On regarde le contenu du fichier et augmente encore la fréquence ensuite ?
[16:19] <sizun_> Ca sert à quelque chose d'augmenter la fréquence?
[16:19] <sizun_> Les FEBs manquent déjà pas mal de trigger signals je pense.
[16:19] <Dirk_> Toujours 60×0 après 240valeurs=60×4pixels
[16:20] <Dirk_> Oui, les FEBs en manquent peut-être. Tu es en random ou fréquence régulière ?
[16:20] <sizun_> Oui, en fait la FEB #7762 utilisait déjà la bonne config.
[16:20] <sizun_> En périodique
[16:22] <Dirk_> Donc, ta limite devrait être 1GHz/(8bits×1894octets/pq) = 65998pq/s
[16:22] <Dirk_> On va à 60kHz ? (Puis 70)
[16:23] <sizun_> Ready for 60 kHz
[16:24] <Dirk_> START - mais fais STOP après 2", sinon on va déborder.
[16:24] <Dirk_> On peut reprendre un run en cours sinon.
[16:25] <Dirk_> 50k evts.
[16:26] <Dirk_> PREPARE(nf=60, 70kHz)
[16:26] <Dirk_> START - Fais environ 1", puis on regarde les compteurs avant de relancer éventuellement.
[16:27] <sizun_> Ready for 70,4 kHz
[16:27] <Dirk_> START - Fais environ 1", puis on regarde les compteurs avant de relancer éventuellement.
[16:28] <sizun_> Done
[16:28] <Dirk_> Nb packets missing            = 3 Nb complete events            = 30932 Nb incomplete events          = 1 -> donc, toujours tout reçu !
[16:28] <sizun_> OK. On s'arrête là?
[16:29] <Dirk_> Pas clair, pourquoi 70kHz passent.
[16:29] <Dirk_> Tu as un compteur pour comparer les triggers entrants dans le FEB et les événements reçus (sortis des FEB) ?
[16:30] <sizun_> Non. On fait un test à 100 kHz?
[16:31] <Dirk_> J'aurais dit 80, 90, 100. On manque toujours de points dans les plots sinon ;-)
[16:31] <Dirk_> Mais attends, je clos le run en cours. On discute encore ici ;-)
[16:32] <sizun_> Ready for 80,3 kHz
[16:32] <Dirk_> START (pendant 1")
[16:33] <sizun_> Run terminé
[16:33] <Dirk_> Oui, cela écrit encore ici.
[16:33] <Dirk_> Nb packets received on time   = 113864 Nb packets received too late  = 0 Nb packets missing            = 4 Nb complete events            = 37954 Nb incomplete events          = 2
[16:34] <Dirk_> 1 événement incomplet. On le cherchera dans le fichier ! ;-) Il doit être perdu autour de 21kE.
[16:34] <sizun_> Ready for 90,3 kHz
[16:35] <Dirk_> START (1" comme d'hab, voire moins)
[16:36] <sizun_> Terminé
[16:37] <Dirk_> Rien perdu. (On n'a eu que 17kE ; c'était très court.) On refait 1" à 90kHz.
[16:37] <sizun_> OK. Prêts?
[16:37] <Dirk_> (C'est le même run pour nous. Tu n'as pas remis les compteurs à zéro ?!)
[16:38] <sizun_> Ils sont a priori remis à zéro à chaque fois
[16:38] <Dirk_> Sinon, on redémarre un run qui commence à evt=0. Attends 3". :-)
[16:39] <Dirk_> START(1" / 100kE)
[16:40] <sizun_> Terminé. Mes secondes sont peut-être un peu courtes.
[16:40] <Dirk_> Oui, 22kE et aucun perdu. On re-PREPARE.
[16:41] <Dirk_> J'efface le dernier fichier.
[16:42] <Dirk_> START(2" ; on est généreux)
[16:42] <sizun_> Terminé
[16:43] <Dirk_> Rien perdu.
[16:43] <Dirk_> On fait un dernier à 100kHz, puis 200kHz ?
[16:45] <sizun_> Ready for 100,2 kHz
[16:45] <Dirk_> Je pense que les FEBs masquent l'excédent de taux et le réduisent aux 66kpq/s limités par la bande passante de 1Gbps. Et l'EVB n'au aucun mal à suivre à cette vitesse (3Gbps sur 10Gbps pour lui).
[16:45] <sizun_> Oui, c'est probable
[16:45] <Dirk_> START(5")
[16:46] <sizun_> Terminé
[16:46] <Dirk_> Je m'attends à voir 5"×66kHz = 330kE, mais je crois que tu n'as fait que 2" ;-)
[16:46] <Dirk_> 138920 événements.
[16:47] <Dirk_> Aucun missing.
[16:47] <sizun_> Je peux recommencer avec un timer
[16:48] <Dirk_> Non, c'est bon. Faisons le 200kHz. Si cela passe, c'est vraiment que les FEBs sont blindés.
[16:48] <Dirk_> A partir de là, on ne pourra avancer qu'en mettant plus de 10 FEBs sur le switch (qui testeront donc les buffers du S60).
[16:49] <Dirk_> PREPARE(200kHz) ?
[16:49] <sizun_> Ready for 202 kHz
[16:50] <Dirk_> START(2")
[16:50] <sizun_> Terminé
[16:50] <Dirk_> Oups. 0 reçus.
[16:51] <Dirk_> re- START(3") ?
[16:51] <sizun_> Starting...
[16:51] <sizun_> Stopped
[16:51] <Dirk_> Non, rien.
[16:51] <Dirk_> Essaie 150kHz ?
[16:52] <Dirk_> START quand tu veux. (L'EVB est en attente d'evt#0.)
[16:52] <sizun_> Terminé.
[16:53] <sizun_> Reçu quelque chose? Je peux reconfigurer les cartes.
[16:53] <Dirk_> Ah oui, si tu n'es pas sûr des cartes, vaut mieux tenter cela.
[16:54] <Dirk_> L'EVB reste en attente evt#0. Donc, si il y a des "paquets de bruit", faut le redémarrer avant le vrai run.
[16:54] <sizun_> Je redémarre à 150 kHz
[16:55] <sizun_> Terminé
[16:55] <sizun_> Toujours rien?
[16:55] <Dirk_> Non, rien.
[16:55] <Dirk_> 140kHz ?
[16:55] <Dirk_> Ou 110, comme tu veux.
[16:56] <sizun_> Je démarre à 110
[16:56] <sizun_> Terminé. Pas mieux?
[16:58] <Dirk_> Non. Je redémarre l'EVB. Après, si cela ne marche toujours pas, il ne reste qu'à repasser à 100.
[16:58] <Dirk_> START(110kHz × 2")
[16:59] <sizun_> Terminé
[17:00] <Dirk_> Rien. START(100kHz)
[17:01] <sizun_> Terminé
[17:01] <Dirk_> Rien.
[17:01] <Dirk_> Qu'est-ce qui a changé ?
[17:02] <sizun_> Je ne vois pas.
[17:02] <sizun_> Je réessaie à 100 kHz
[17:03] <Dirk_> Ah, je croyais que c'était fait. Oui, vas-y !
[17:03] <sizun_> C'était fait, mais je viens de réessayer en réglant le géné à 100kHz depuis une décade différente juste pour voir.
[17:03] <Dirk_> OK. START
[17:04] <sizun_> Terminé
[17:04] <Dirk_> Rien.
[17:04] <sizun_> OK. Je vais faire un run à nf="30" et 30 kHz avec qNectarcam pour voir
[17:05] <Dirk_> OK.
[17:07] <sizun_> Rien
[17:07] <Dirk_> Ah. Cartes kaputt ?
[17:08] <sizun_> Pas de problème pour communiquer avec elles
[17:08] <Dirk_> "Les tests ont montré qu'avec un taux de trigger de 100kHz, on peut exploser les modules Nectar." :-)
[17:08] <sizun_> C'est réparé
[17:08] <Dirk_> Oui, mais le module de trigger est peut-être à plat. Je vais voir, si FT est encore en ligne.
[17:09] <sizun_> L'alim de la carte de trigger s'était coupée
[17:09] <Dirk_> Bien ! (de l'avoir trouvé)
[17:09] <Dirk_> On recommence à 200kHz tout de suite ?
[17:09] <sizun_> Ok, on recommence 100kHz puis 200 kHz?
[17:09] <sizun_> OK pour 200kHz
[17:10] <Dirk_> START(200kHz×2")
[17:11] <sizun_> Starting
[17:11] <sizun_> Terminé
[17:11] <Dirk_> Parfait.
[17:21] <FT_> bravo
[17:30] <Dirk_> @FT, tu as compris que la FEB résiste à 200kHz sans perdre le Nord ? Elle perd certes quelques triggers, mais arrive garder en bonne santé les compteurs, BUSY et autres.
[17:31] <FT_> bonne nouvelle donc ?
[17:31] <Dirk_> Très bonne nouvelle.
[17:31] <FT_> super chouette non ?
[17:32] <Dirk_> Oui, oui, et PatrickN mérite une médaille pour la réalisation de la DAQ de ces cartes jusqu'à nouvel avis. (Il faudrait faire un test pendant une nuit ou un week-end pour voir la fiabilité.)
[17:33] == sizun_ [84a624fc@gateway/web/freenode/ip.132.166.36.252] has quit [Quit: Page closed]