MBS is currently configured and accepting data:

x86l-94 : AIDA Foreign data receiver

x86l-4 : DESPEC Time sorter

The time sorter is complaining about AIDA time warps (around 1 Hz) it is assumed this is related to other merger / timestamping issues being worked on by Vic

To start the MBS Data Relay, click on the top rightmost of the MIDAS icons (MBS relay, Data Relay => MBS) in
Desktop 3. (attachment 1)

This will bring up the Data Relay MBS terminal.

Ensure the path defined in the datarelaymbs is set to the correct directory (shown in attachment 2) 

AIDA@DESPEC MACB time switch settings before and after WR are as follows.

Attachment 1 - MACB 1-4 from left to right

MACB number:                           1        2        3        4

100MHZ clock setting (before WR):      0        2        2        2

White Rabbit setting (after WR):       3        3        3        3

When using the VETAR connected to the HDMI port of the root MACB the settings for all the MACB in the system 0x3.

This setting takes the Clock and Data line from the input HDMI and outputs it via teh HDMI output ports.

When using the Emulator connected via the SMA connectors on the back of the root MACB then the setting for the root MACB should be 0xD and all others should be 0x3.

Attached is the .jed file for programming the MACB and the .vhd source file to help with understanding of the settings.

Pictures of leaking cooling pipe

MACB switch settings

AIDA mount - needs rotated

Attachment 11 - AIDA@DESPEC MACB settings - 100MHz and WR

During the installation of the 4 new HDMI cables for aidas13-16 the HDMI cables between the MACB Root and the MACB leaves were looped through the cable guide at the top to support them more
This may improve their connection and reduce the chance of WR errors seen in S460/S452
The connectors were all reseated a few times to clean the contacts too

The rate is very low in all aida, not sure .

This was because the statistics page had been changed to transfer buffers. The rates were ok

The behaviour of the DSSSD leakage current at low voltages and during biases is unusual and varies depending on how the adapter boards are connected
To summarise the behaviour I have observed

Minimum bias configuration:
 4 adapter boards, one n+n (LK1), three p+n (-ve bias), ground from n+n to one p+n
 Voltage (and leakage current) unstable at low voltages, seems to settle at around -60 V
 Drops can include 0 leakage current

Full adapter configuration:
 8 adapter boards, ground ring complete
 Same as minimum, but the drops seem to be much smaller (and not to 0 leakage current)
 -60V again seems to be the turnover to a stable leakage current 

In both cases the leakage current during ramping appears basically the same as when settled

Full into FEEs
 8 adapter boards, fully connected to 8 FEEs
 The leakage current is *much* higher during ramp,up to 17 uA near the end. No fluctuations
 Once ramping has finished the current quickly drops back down and settles at the nominal leakage current
 This has been observed in October/December too, it is not new (https://elog.ph.ed.ac.uk/AIDA/910)
 During power up of the FEEs the current sometimes drops briefly (when the ASICs get programmed, I believe)


I think it is related to the ground (more or less current flowing through the HV supply instead of alternate paths?)
It should be kept in mind when testing new detectors to not worry about the detector at low voltages

LEC fast comparator has been set to 0x2 (200keV) which is *very* low and means the fast comparator will be triggering on noise.

The *minimum* LEC fast comparator setting should be in the range 0x5 - 0xa (500-1000keV).

I have set the TapeServer to 'no storage' mode to avoid filling the aida-gsi disk with rubbish.

> 
> LEC fast comparator has been set to 0x2 (200keV) which is *very* low and means the fast comparator will be triggering on noise.
> 
> The *minimum* LEC fast comparator setting should be in the range 0x5 - 0xa (500-1000keV).
> 
> I have set the TapeServer to 'no storage' mode to avoid filling the aida-gsi disk with rubbish.

Thanks. From the DESPEC elog.gsi.de/despec/Implantation+Stack/18

"We have made a trigger from the BGO logic and OR64 of the fast discriminator from AIDA. This was sent as a trigger to the bPlast Exploder.

This did not work as the FEE64s of AIDA are running into high dead-time and a result are dropping data. This is a problem for the ucesb unpacker as it will quite working if one of the subsystem stops sending data. (@Nic is this correct?)

This is indeed what I see as whenever we try to run FAIRROOT the tree builder exits immediately."

> > 
> > LEC fast comparator has been set to 0x2 (200keV) which is *very* low and means the fast comparator will be triggering on noise.
> > 
> > The *minimum* LEC fast comparator setting should be in the range 0x5 - 0xa (500-1000keV).
> > 
> > I have set the TapeServer to 'no storage' mode to avoid filling the aida-gsi disk with rubbish.
> 
> Thanks. From the DESPEC elog.gsi.de/despec/Implantation+Stack/18
> 
> "We have made a trigger from the BGO logic and OR64 of the fast discriminator from AIDA. This was sent as a trigger to the bPlast Exploder.
> 
> This did not work as the FEE64s of AIDA are running into high dead-time and a result are dropping data. This is a problem for the ucesb unpacker as it will quite working if one of the subsystem stops sending data. (@Nic is this correct?)
> 
> This is indeed what I see as whenever we try to run FAIRROOT the tree builder exits immediately."

We have increased the all thresholds excluding aida10 to 0xff. To not trigger on the other FEEs, however better, the DAQ still occasionally runs into dead time and as such fails with making trees.

We have thus elected to turn off AIDA and move out the platform. The conclusion is that we are not able to do this fast timing test with a 200 keV threshold.

> > > 
> > > LEC fast comparator has been set to 0x2 (200keV) which is *very* low and means the fast comparator will be triggering on noise.
> > > 
> > > The *minimum* LEC fast comparator setting should be in the range 0x5 - 0xa (500-1000keV).
> > > 
> > > I have set the TapeServer to 'no storage' mode to avoid filling the aida-gsi disk with rubbish.
> > 
> > Thanks. From the DESPEC elog.gsi.de/despec/Implantation+Stack/18
> > 
> > "We have made a trigger from the BGO logic and OR64 of the fast discriminator from AIDA. This was sent as a trigger to the bPlast Exploder.
> > 
> > This did not work as the FEE64s of AIDA are running into high dead-time and a result are dropping data. This is a problem for the ucesb unpacker as it will quite working if one of the subsystem stops sending 
data. (@Nic is this correct?)
> > 
> > This is indeed what I see as whenever we try to run FAIRROOT the tree builder exits immediately."
> 
> We have increased the all thresholds excluding aida10 to 0xff. To not trigger on the other FEEs, however better, the DAQ still occasionally runs into dead time and as such fails with making trees.
> 
> We have thus elected to turn off AIDA and move out the platform. The conclusion is that we are not able to do this fast timing test with a 200 keV threshold.

Per our discussions in December 2024 this is exactly what would be expected.

10.30 AIDA setup and DAQ start complete
      writing to file TapeData/NULL/R1

      FEE64 Temperatures and Good event statistics ok (attachments 1 and 2)

11.00 results of analyser - shows significant number of timewarps in aida07, and a few in aida01-04

11.24 compared timestamps between mbs and AIDA, agree to 8 digits (attachment 3)

12.49 DAQ and Merger stopped and restarted

      Raised slow comparator threshold from 0xa to 0x64

      Raised fast comparator threshold (LEC/MEC) from 0xf to 0xff

12.51 Good event statistics: aida08 running at a normal rate

      pulser peak (1.8.L) no longer has noise shoulder (attachment 4)

      writing to file TapeData/NULL/R2


13.58 stopped writing to file. Pulser frequency increased to 1 kHz

      writing to file TapeData/NULL/R3

15.00 file R4 - DAQ startup

17.58 trimmed and re-crimped ground wire on aida08
      lowered pulser freq back to 50Hz
      reduced slow comparator threshold to 0xa, fast comparator threshold (LEC) to 0xf

      good event stats ok, aida08 no longer running hot (attachment 6)
      1.8.L and 1.8.W spectra of aida08 (attachment 5)
      pulser peak width now at 55.71

      FEE64 temperatures ok (attachment 7)

Post White Rabbit update

Attachment 1 - 1.8.W pulser waveform spectra for all FEE64
             - pulser signals observed in all FEE64

Attachment 2 - good event statistics - aida08 has significant noise

Attachment 3 - FEE64 temperatures - all ok, but firmware version not displayed

Attachment 4 - 1.8.L pulser peak spectra

             - widths:

             aida01 - 23.66
             aida02 - 19.76
             aida03 - 20.43
             aida04 - 18.82
             aida05 - 20.05
             aida06 - 41.04
             aida07 - 21.24
             aida08 - 205.02 (noisy FEE64)
             aida09 - 24.81
             aida10 - 22.85
             aida11 - 13.98
             aida12 - 19.90

Attachment 5 - New Merger statistics

Attachment 6 - Raw data stream

Attachment 1 - 1.8.W waveform spectra with pulser signal

Attachment 2 - 1.8.L pulser peak spectra

widths: aida01 - 16.06
       
        aida04 - 20.68

        aida05 - 14.03

        aida08 - 73.02

        aida09 - 669.29

        aida11 - 405.35

        aida12 - 397.6

Attachment 3 - good event statistics
               fast comparator threshold (LEC) at 0xff
               FEEs 8,9,11,12 running hot

Attachment 4 - FEE64 temperatures - all ok

System wide checks ok, except aida02 fails ADC calibration

Leak found in seal on cooling pipe, switched power off

Some additional checks

- check 'top hat' electrical isolators are correctly installed at each of the 4x mounting points of the AIDA snout assembly

- check snout is electrically isolated with respect to AIDA support assembly/stand, bPlas PCBs/cabling/ground/drain wires and BB7

- check LK1 installed aida02 or aida04 *and* aida06 or aida08 ( I assume these are the n+n Ohmic FEE64s? )

- check LK3 installed bottom, middle p+n junction FEE64s ( i.e. LK3 installed on 2 of 16 FEE64 adaptor PCBs )

- check FEE64 power cables are paired correctly, e.g. aida02 & aida04, aida01 & aida03 etc. Remember that the numbering of the power cables at the FEE64 PSUs may no longer correspond to which FEE64 is actually connected to that cable

- check test  and test - cable daisy chains are removed

- check ground cabling attachment to Lemo 00.250 connectors is tight - they have tendency to loosen with handling

Mounted on frame:

DSSD 1 (Upstream) :     3208-2/3208-5/3208-8
DSSD 2 (Downstream): 3208-3/3208-21/3208-22

Current mapping has been redone for better management.

Going to try optimising noise now.

DHCP updated

new ASIC settings: 2024Mar27-11.25.32 - 16 FEEs (2,4,6,8 n+n, rest p+n)

New layouts: /home/npg/LayOut/GSI_Triple_S100

New layout.txt

Firmware of aida11 updated from 0xea40704 to 0x3350706

Temps GOOD fig 5

Rates fig 6, 7

Check adapter alignment aida14 and aida16

bPlas left/right cables are not insulated and shorting to the snout

Logs on nnpi1 archived and deleted, start again
All 16 FEEs are showing USB logging connectivity and can be monitored with Pi_Monitor

From waveforms aida08 and aida16 are quite unhappy. The rest don't seem too bad. DSSSD 1 is much quieter than it was before!

White Rabbit Analysis: aida02 has lots of WR error counter, HDMI reseat needed
aida09-12 have no WR timestamp, the cable to the MACB is bad or the MACB is bad.
Not needed to fix right now (for noise testing)

Turn off bPlas
We see the noise drop a lot

Some additional checks

- check 'top hat' electrical isolators are correctly installed at each of the 4x mounting points of the AIDA snout assembly 

- check snout is electrically isolated with respect to AIDA support assembly/stand, bPlas PCBs/cabling/ground/drain wires and BB7

- check LK1 installed aida02 or aida04 *and* aida06 or aida08 ( I assume these are the n+n Ohmic FEE64s? )

- check LK3 installed bottom, middle p+n junction FEE64s ( i.e. LK3 installed on 2 of 16 FEE64 adaptor PCBs )

- check FEE64 power cables are paired correctly, e.g. aida02 & aida04, aida01 & aida03 etc. Remember that the numbering of the power cables at the FEE64 PSUs may no longer correspond to which FEE64 is actually connected to that cable

- check test  and test - cable daisy chains are removed

- check ground cabling attachment to Lemo 00.250 connectors is tight - they have tendency to loosen with handling