Present: Juan Palacios González, Agustín Sánchez Losa, Francisco Salesa Greus, Bruny Baret, Benjamin Trocmé

A priori, the intra-DU timing provided by the lab/dark room measurement is already pretty accurate. A priori, they are good enough for most of DOMs except some for which no data are not available.

The geometry retrieved from the DB is then used to complete the correction. In most of the case, this is the static positioning calibration (Process A) that is used, given the delay to compute the dynamic positioning (Process C). But if the dynamic positioning is available, the scripts can use them without problem. 

Currently, the offsets found by the nanobeacon are not yet used. Assuming that the timing should not change too much, the nanobeacon runs (in ORCA only) are mainly used as a monitoring/check tool. It is better to perform an in-depth analysis DU per DU. The accuracies as found by the current method (see slide #2 and #10) are within 5ns and pretty stable. This could be explained by several causes (line stretching, propagation speed...). Using the dynamic positioning could help. 

• Action: interact with Lilian (coordinator of positioning subgroup) to find an easy way to retrieve the dynamic positioning used in mass processing.

Data taking considerations (ORCA)

The nanobeacons calibration runs are largely affected by the HRV that lead to a large inefficiency. To cope with this, two options can be considered:

1. disable the high rate veto with the trigger parameter disableHighRateVeto.
2. tune the nanobeacon high voltage.

As DAQ experts dislike option #1 that may be dangerous, it was decided to adopt #2. An optimal value of 7.75V was derived and tested in ORCA just before the data taking stop (Januray 2024)

• Action: understand with the operation team whether this was propagated in all calibration setups.

Currently, the calibration are completed per DU, hence 1 run per DU. It is proposed to switch to a per-floor scheme (see slide #13) to keep the calibration time under control. 

The generation of runsetup file are apparently very complicated. An automatic generation by a tool common to ARCA/ORCA would be very welcome in the future to switch to the per-floor scheme, easily scale the system when adding new lines and acquire calibration runs in ARCA (never implemented).

• Action: develop an automatic generation tool.

Specific case of ARCA

As of today, no nanobeacon run was acquired by ARCA. 

The main difference with ORCA is inter-DOM distance: flashing only one DOM would degrade the performances (loss of redundancy); increasing the time window would be a solution. 

As there is no expertise to tune the Voltage for ARCA, the same voltage (7.75V) used for ORCA should be OK also for ARCA (no reason to see a HRV degradation). ARCA could try to run with HRV disabled.