1. Receiving 91 PB this week: A little bit more of work load! (We will be for a while production guys :) Test bench separated in two parts: 1.- The PB will be supplied with 12 V. All voltages will be measured in open circuit. If ok it will pass to the next part of test. 2.- The PB will be connected to one test CLB. The voltages will be measured there. Also will be checked that the FPGA is configured and that the Nanobeacon flash (to check the I2C bus of the PB – The FPGA will be programed to allow this) Crossing fingers to not find big problems. Once the first is tested successfully (we will know that there are not big issues) we will tell Paolo&Antonio. How much are needed in Genova? 60? Btw: It will possible to send 2-3 CLBs to the IFIC. We have only 2. 1

2. 2 Syncro Tests

3. Data Transmission & Synchronization setup

4. Synchronization results in broadcast mode Loss of sync with increasing: – Data rate – UDP packet size – Time slice duration

5. Mieke, Riccardo, Vincent, Peter and David (I forgot someone else?) Data transmission rate + synchronization obtained with one CLB : Proposed plan: 1.- To continue struggling to disentangle the ropes of the broadcast. This week. 2.- If not working as the WR standard next one David and I will pay a visit to 7S (Now that we know that the CLB works in the standard WR) with all the IFIC system (WR switches, transceivers, CLB, PCs, etc) Note: With the synchronization we have also a very bad time in the past to pass from the standard to the broadcast, until in Valencia test 7S solved quite fast. 5 WR standard200 Mbits / secPPS on WR Broadcast200 KbpsPPS on WR broadcast2 Mbits / secPPS not always on WR broadcast200 Mbits/ secNot yet

6. 10 meters Interswitch transceivers: Broadcast: AXGE-1254-0531 (blue) Level 1: AXGE-3454-0531 (purple) Switches-CLB transceivers: ACFT-5710PZ Optical Ethernet + Wireshark 6 meters 10 meters 6 meters It will be possible to evaluate the Bandwidth of the broadcast channel? Include also CLB & SPECs in mode broadcast and evaluate the syncronization: PPS 6 What about the broadcast link?

7. Creotech offer 7 Can someone buy 1,2 or 3 Switches for evaluation?

8. ReX and feedback for the quality group (I) 1.- No NCRs for developments currently on going. But we need to use a system to track what was tested, where and the results obtained. Bologna system (wiki based) seems quite good. Could we implement it for the data&syncro development and test? We also need to implement a system to help integration people to find and track easily the bit and bin files to use (firmware + software included) 8

9. ReX and feedback for the quality group (II) 2.- One detector, one protocol (Lets made it as simple as possible, but not simpler). Homogeneity: quality by design, not by testing. 1.-DU base (Absolute Time: Key point of the detector, effort needed here ) 2.- Calibration 3.- DOMs Struggling with one protocol is already quite difficult, if we have to use or interface several of them it is going to be the worst of our nightmare. (Continue, with lower priority, with the evaluation of other options) 9

10. ReX and feedback for the quality group (III) 3.- For Phase 1.5: One detector, one STANDARD protocol: Current experience with the broadcast (deviation from WR standard) is really bad (people working currently on it, please comment your RceX: Return of current Experience) Standard = highest quality Deviations from the standard or completely new approaches, make walking, if possible, quite difficult (mountain pass in winter) Standards allow to drive for well known and maintained paths quite fast … like neutrinos (highways) 10

11. Quality group: Put KM3NeT in homogenous and standard mode: Highest Quality Meanwhile we will continue struggling badly to disentangle the “broadcast” ropes And remember, Highest quality is always the lowest total cost!! Slide from the talk in the KM3NeT Q Workshop of my friend and Quality Teacher Stefano Cecchini https://indico.cern.ch/event/289541/session/1/material/0/0.pdf 11