********************************************
** Setup of DAQ x86l-131 (outside pocket) **
********************************************

Used FEBEX GUI to set thresholds for all channels.
Using ~65 mV pulser input, find 3000/0xbb8 (decimal/hex) to be a robust level where pulser is always seen and the trigger level is well above noise.
We expect much higher real detector signals so this should be an appropriate trigger.

Set channel trigger mask to:
0x0000, 0x,0000, 0x0000, 0xcf57

This will trigger readout on n-sides 1-3, 5, 7, the DSSD and the crystal PD.
(pad in slot #7 = pad 6)
Triggers are turned off for all p-strips, unconnected channels and the n-side of pad 4 since that cannot be properly biased.

See some high frequency noise on all channels so extended integration time of hit finder to integrate this out.
Hit finder params set to:
TRIG_SUM_A 20
TRIG_GAP   10
TRIG_SUM_B 21

Trace length (FEB_TRIG_LEN) is set at 3000 and the trigger delay at (FEB_TRIG_DELAY) 500

Sparsifying turned on so if the hit finder doesn't find at least one hit on a given channel, the trace for that channel will not be saved.

*******************************************
** Setup of DAQ x86l-124 (inside pocket) **
*******************************************

The inner pocket n-sides seem to see more noise and the trigger rate is not as stable -> additional component due to fluctuating noise.
Set up similarly to x86l-131 in terms of hit finder parameters, thresholds etc.

Trigger mask is set to:
0x0000, 0x,0000, 0x0000, 0xcf5b

This will trigger readout on n-sides 1,2,4,5,7, the DSSD and the crystal PD.
Triggers are turned off for all p-strips, unconnected channels and the n-side of pad 3 since that cannot be properly biased.

Data files written to /mnt/raw.data/e0203_e0018.

From MBS computers:
cd exp_mnt/data.ESR/e0203_e0018/run***.lmd

Everything called run*** is from timesorter.
Everything with a number (either 124 or 131) before run is from one of the independent DAQs.

Sample file taken with pulser to inside DAQs (124) and written to 124_run0001.lmd.

The MHV modules are set up for remote control. This can be accessed via the mesycontrol software running on x86l-128.

A configuration file has been save to: esr/usr/litv-exp/DAQ-control/mesycontrol/pleiades_2025_v2.xml

DAQ OPERATION

The files of each MBS node or the timesorter are written to the ESR NAS by the RFIO server.
The server is running on the virtual machine atprfio.gsi.de. 
The NAS is mounted there and we write data to the subfolder: /mnt/raw.data/e0203_e0018/

This folder can be mounted to any x86l-XXX pc using litv-exp user with the shell command
> mountESR
The NAS is then mounted at /esr/usr/litv-exp/exp_mnt/data.ESR 
Which is where you will find the folder e0203_e0018 and the data.

We started inserting the inside and outside detector, see
https://elog.gsi.de/esr/E0203_E0018/46

Outside detector (131): started beam scraping at -40mm, at -35mm no beam left
Inside detector (124): drove it in up to 2mm, no beam scraping seen.

MBS files: run0010.lmd (outside detector, ~14:25)
run0011.lmd (16:50): first inside detector, then also testing outside detector again
run0012.lmd: running now with both detectors in:

inner detector: BGO
device: GE01DD2IG 
position: +20mm
scraping beam: not possible

outer detector: GAGG
device: GE01DD2AG
position: -55mm
scraping beam at: -45mm

The experiment has been running stably during the afternoon.
DAQ rates have remained constant and the frequency of hits in the Go4 has remained 1 hit every ~few mins.

However, leakage currents have increased significantly in most detectors, by up to a factor of 20x times in some.

I find it hard to see how radiation damage could cause this, but using the rule of thumb of 2x current for 8C rise in temperature, this would imply a >35C rise. This also doesn't seem realistic.

I don't currently have any other ideas.

Attached is the current leakage current plot - it is clear they have been increasing linearly since this afternoon.

Due to the continued rise in leakage currents, I have stopped the run, moved the detectors completely back and turned off the 
bias to all detectors.

-X86L-128:transport  :-I- remote output file /mnt/raw.data/e0203_e0018/run0015.lmd closed
-X86L-128:transport  :Rfio server atprfio: closed file after    999.981 MB, open next:
-X86L-128:transport  :/mnt/raw.data/e0203_e0018/run0015.lmd
-X86L-128:transport  :/mnt/raw.data/e0203_e0018/run0016.lmd
-X86L-128:to         :error (no timeout) getting event from node X86L-124,
-X86L-128:to         :exiting..
close file
-X86L-128:transport  :closed file after    338.199 MB written:
-X86L-128:transport  :-I- remote output file /mnt/raw.data/e0203_e0018/run0016.lmd closed
-X86L-128:transport  :/mnt/raw.data/e0203_e0018/run0016.lmd

The settings of the MBS daq during the first data taking with fragments around 194Pb (W.Korten experiment) was not entirely correct:

1. both FEBEX nodes had the very same sub-sytem identifier 0x200. The timesorter did merge the two data streams into the lmd files. Now the events cannot be easily separated/identified, 
because both have the same WR header. The only option to identify which FEBEX was the source for an event might be to look for the actual channels receiving hits, because they are slightly 
different for both arrays/DAQs. This might only work for "good" events though...

2. The trigger signals transmitted to the scaler DAQs (VME & NTCAP) had a different input for both DAQs. The GAGG trigger (outside) was using the FEBEX self-trigger as input only, while 
the BGO trigger (inside) was using the FEBEX self-trigger OR the 10Hz sync trigger as input.

The runs with run number lower than 0016 are affected by the above points.

Now the setup has been changed, for run numbers 0017 and higher the following should be valid:

1. WR identifiers
The BGO DAQ on x86l-124 (inside) does use WR sub-system identifier 0x100
The GAGG DAQ on x86l-131 (outside) does use WR sub-system identifier 0x200
The VME DAQ on x86l-204 does use 0x400

2. transmitted triggers
Both DAQs now transmit only the FEBEX self-trigger to the scaler DAQs.

3. Gate Generator for PEXARIA input
We now use a Gate Generator to provide 200ns TTL signals for the PEXARIA, with the goal of avoiding double trigger/pulses (a known issue of the old EXPLODERs we are using)

4. SPARSIFYING
We turned off SPARSIFYING for both FEBEX DAQs. So 
in f_user.c 
#define DATA_FILT_CONTROL_DAT 0x80
was changed t0
#define DATA_FILT_CONTROL_DAT 0x82

During an access break to the ESR, I made a few tests with the bias scheme to see if we could better understand some of the weird quirks.

Two detectors showed likely shorts during initial setup - these detectors were still cabled to the bias network though. 
If there is a short to ground, we wondered if that could then impact the other detectors on the same MHV4 module.
These detectors were uncabled at the pre-amp end.
No change was noticed we bias was applied again.

On the outside pocket, I also noticed that when one detector is turned off, the leakage currents of the others remain the same amplitude but flip polarity as the other biases down.
I disconnected all detectors from that MHV module and connected them one-by-one and this effect was immediately seen with two detectors connected.
I double-checked the cabling and cannot see anything wrong there.

Please enter the leakage currents from the mesycontrol every ~1h into this Google document:

https://docs.google.com/spreadsheets/d/1Gt1tFHwn4XFrJ5_-nQvTi635UD0aHgN6gCdXDTHQdkI/edit?gid=299353113#gid=299353113

The inner detector was moved into position.
The device control for the outer detector is not responding and I am not an expert/don't know how to make it work.

See ELog: https://elog.gsi.de/esr/E0203_E0018/126

Inner detector (x86l-124 BGO)
Device: GE01DD2IG
Position: +20 mm
Scraping beam: not possible

At 19:00 the timesorter slowed down and stopped responding. at 19:56 the the inner detector was retracted (pulled back further from the beam)

Outer detector (x86l-131 GAGG)
Device: GE01DD2AG
Position: -127 mm
Scraping beam: n/a

This could be an interesting test of the detector leakage current response to being in place (i.e. only the inner detector is in place, do all leakage currents increase or 
only that detector?)

Started taking data with file run0017.lmd @ 17:35.

Will continue to run for a few hours this evening and closely monitor leakage currents.

Go4 is running on x86l-184 connected to stream server.