> > > 
> > > 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.

> > 
> > 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."

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.

16:30 We moved the platform in. The system was still biased and the DAQ was still running.

The system seems to be okay, temperatures OK. Bias voltage OK 685/1 and 685/2. Two FEEs - aida07 and aida12 are receiving a lot of trigger data items from the fast discriminator. This is already a bit worrying. 685/3

Initial results: copy from DESPEC elog.

We have managed to obtain the time difference between the bPlast White rabbit and the AIDA Fast time. We had to gate out the zero fast-time events and then also condition that we only take the data from aida10. We see this in 684/1. Then if we look at the time difference between the fast time and the bPlast WRT we see a sharp peak at zero, this makes sense as the AIDA fast time discriminator is being triggered by a pulser which is then being used as a trigger for bPlasts DAQ so these events should be virtually arriving without delay. The delay we do see is infact around 750 ns.

The data collected overnight was also analysed as shown in 684/3 this is the data accumulated with the 22Na source close to the snout and a global threshold in the fast discriminator of 0x0f. The centre peak was roughly fitted with a gaussian:    

  NO.   NAME      VALUE            ERROR          SIZE      DERIVATIVE 
   1  Constant     1.21277e+03   2.74526e+01   5.66915e-01  -5.61074e-07
   2  Mean        -1.78513e+02   8.50699e+00   1.62947e-01   1.58554e-06
   3  Sigma        3.48571e+02   4.03993e+00   6.26343e-05  -1.86863e-03

The pulser was set to 0.5 V to test if we can still see the time spectrum between AIDA and bPlast with reduced thresholds -- mimicking a beta event.

These thresholds were changes from 0x32, 0x20, 0x20, 0x11 for ASIC 1,2,3,4 ---> 0x10, 0x10, 0x0d, 0x10.

This was set to have the HitRate in aida10 to be just above the noise.

8:01:25/11:42:48|0x000000d00000-0x000000fe0000 : "user_kernel"
08:01:25/11:42:48|0x000000fe0000-0x000001000000 : "env_variables"
08:01:25/11:42:48|xilinx-xps-spi 81400400.hd-xps-spi: at 0x81400400 mapped to 0xD1028400, irq=20
08:01:25/11:42:48|SPI: XIlinx spi: bus number now 32766
08:01:25/11:42:48|xilinx-xps-spi 81400000.xps-spi: at 0x81400000 mapped to 0xD102C000, irq=21
08:01:25/11:42:48|SPI: XIlinx spi: bus number now 32765
08:01:25/11:42:48|mice: PS/2 mouse device common for all mice
08:01:25/11:42:48|Device Tree Probing 'i2c'
08:01:25/11:42:48| #0 at 0x81600000 mapped to 0xD1030000, irq=22
08:01:25/11:42:48|at24 0-0050: 1024 byte 24c08 EEPROM (writable)
08:01:25/11:42:48|TCP cubic registered
08:01:25/11:42:48|NET: Registered protocol family 17
08:01:25/11:42:48|RPC: Registered udp transport module.
08:01:25/11:42:49|RPC: Registered tcp transport module.
08:01:25/11:42:49|eth0: XLlTemac: Options: 0x3fa
08:01:25/11:42:49|eth0: XLlTemac: allocating interrupt 19 for dma mode tx.
08:01:25/11:42:49|eth0: XLlTemac: allocating interrupt 18 for dma mode rx.
08:01:25/11:42:49|eth0: XLlTemac: speed set to 1000Mb/s
08:01:25/11:42:51|eth0: XLlTemac: Send Threshold = 24, Receive Threshold = 4
08:01:25/11:42:51|eth0: XLlTemac: Send Wait bound = 254, Receive Wait bound = 254
08:01:25/11:42:51|Sending DHCP requests .
08:01:25/11:42:53|eth0: XLlTemac: PHY Link carrier lost.
08:01:25/11:42:53|..... timed out!
08:01:25/11:44:15|IP-Config: Reopening network devices...
08:01:25/11:44:15|eth0: XLlTemac: Options: 0x3fa
08:01:25/11:44:16|eth0: XLlTemac: allocating interrupt 19 for dma mode tx.
08:01:25/11:44:16|eth0: XLlTemac: allocating interrupt 18 for dma mode rx.
08:01:25/11:44:16|eth0: XLlTemac: speed set to 1000Mb/s
08:01:25/11:44:18|eth0: XLlTemac: Send Threshold = 24, Receive Threshold = 4
08:01:25/11:44:18|eth0: XLlTemac: Send Wait bound = 254, Receive Wait bound = 254
08:01:25/11:44:18|Sending DHCP requests ...... timed out!
08:01:25/11:45:35|IP-Config: Auto-configuration of network failed.
08:01:25/11:45:35|Root-NFS: No NFS server available, giving up.
08:01:25/11:45:35|VFS: Unable to mount root fs via NFS, trying floppy.
08:01:25/11:45:35|VFS: Cannot open root device "nfs" or unknown-block(2,0)
08:01:25/11:45:35|Please append a correct "root=" boot option; here are the available partitions:
08:01:25/11:45:35|Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
08:01:25/11:45:35|Call Trace:
08:01:25/11:45:35|[c6827ed0] [c0005de8] show_stack+0x44/0x16c (unreliable)
08:01:25/11:45:35|[c6827f10] [c00345bc] panic+0x94/0x168
08:01:25/11:45:35|[c6827f60] [c0341d34] mount_block_root+0x12c/0x244
08:01:25/11:45:36|[c6827fb0] [c03420d8] prepare_namespace+0x17c/0x208
08:01:25/11:45:36|[c6827fd0] [c0341220] kernel_init+0x104/0x130
08:01:25/11:45:36|[c6827ff0] [c000e140] kernel_thread+0x4c/0x68
08:01:25/11:45:36|Rebooting in 180 seconds..

Yesterday we spent time essentially performing a dry run to get AIDA DAQ and bPlast into the time sorter, there were some issues with the AIDA mbs PC x86l-119 which was related to some boot issue, it was booting to a newer version of debian while the Relay for AIDA to MBS is on an older version (scratch) (the machine is quite old). We spent a bit of time getting the thresholds correct for each of the ASICs. In the end we just elected to have a blanket level of 0x0f for all of the ASICs when we removed the pulser.

Last night we left the setup with the following thresholds on all of the FEEs to collect data. 681/1. The pulser was also turned off and the 22Na source was moved close to the snout.

This morning c. 9:25 we returned and checked the temperatures, HV and statistics and everything seems to be ok. The only problem was that the timesorter has crashed this morning at 8 am.

See also https://elog.ph.ed.ac.uk/CARME/489

1. Establish port (to access carme-gsi)               ssh -L 8080:proxy.gsi.de:8080 carme@atppc025

   Establish port (to access aida-gsi)                ssh -L 3128:proxy.gsi.de:3128 despec@lxlogin

   Once a port is established it will remain accessible (until next system boot?) even if ssh connection drops/closes

2. Check AnyDesk password for remote access has been set up

3. Close anydesk and check it is *really* closed using

ps -o pid= -C anydesk

kill -9 any process (as root)

4 Restart AnyDesk

systemctl restart anydesk (as npg)

11.54 re-established remote access via AnyDesk - details to follow

      confirmed AIDA FEE64 power OFF, detector HV OFF


1. Establish port (to access carme-gsi)               ssh -L 8080:proxy.gsi.de:8080 carme@atppc025

   Establish port (to access aida-gsi)                ssh -L 3128:proxy.gsi.de:3128 despec@lxlogin

   Once a port is established it will remain accessible (until next system boot?) even if ssh connection drops/closes

2. Check AnyDesk password for remote access has been set up

3. Close anydesk and check it is *really* closed using

ps -o pid= -C anydesk

kill -9 any process (as root)

4 Restart AnyDesk

systemctl restart anydesk (as npg)

678/1 shows the AIDA OR64 trigger from the fast comparator of aida10.

678/2-4 show the bPlast accepted trigger after the bPlast DAQ has been triggered by the AIDA OR64. The images show a signal coming fast in time after the pulser and also a signal at around 80 us that appears to be coming from pile up.

The bPlast DAQ also now runs with the AIDA OR64 trigger after the NIM out signal from the MACB was sent to an octal discriminator to fix the width of the signal and also the pulse width which from TAMEX should be kept at or above 100 ns. The NIM signal from the MACB was mostly 100 ns but also jumping to signals with a 20ns pulse width.

https://elog.gsi.de/despec/Implantation+Stack/9?suppress=1 - Day 1 ELOG

Day2:

10:14 we set up the detector with the pulser in BB7 and started biasing the detector and setting up the DAQ. Water flow and temperature check, OK. 677/1 677/2 677/3

FEE temps OK. Screenshots included for LOCAL controls for aida07, Discriminator for aida07, ASIC control for aida01 ASIC # 1,2,3,4 and the pulser setting - 1 V @ 10 Hz rep. 677/4 677/5 677/6 677/7 677/8 677/9

ASIC thresholds for the fast comparator LEC/MEC set to 0x20 for all the ASICs in aida10 - connected to BB7. Act on all ASICs did not work with this so each threshold was set to 0x20 on each ASIC by hand.

The pulser is now connected to BB7 test + and via a T-connector to the scope, triggering on the pulser signal. We saw now signals --> lower the threshold of the fast comparator to 1 MeV - 0x64 on all ASICs in aida10. 677/10

No signal was observed, threshold was then set to 0x190 (400 keV) 677/11

13:00 We resumed after lunch. It seems that our thresholds were way too high for starters each channel was actually 100 keV in HEX. We then set the thresholds in aida10 to 0x32, 0x20, 0x20, 0x11 for ASIC 1,2,3,4, respectively. This was to achieve a 10 Hz hit rate in all of the channels! This was done successfully see 677/12 for the hit rate spectrum and also 677/13-16 for the thresholds.

11:00 Visual inspection FEE64 adaptor PCBs & cabling
      aida02 ground from/to other FEE64s disconnected - re-connected
      aida01, aida09, aida12 - ground cabling screws to Lemo 00.250 housings loose - tightemed

12:50 Cooling water pressure & temperature OK - attachments 1  2

12:59 relay #1 power ON

13:01 relay #2 power ON

13:07 aida06 starts - panic during startup, automatic restart following 3 minute timeout

      DAQ reset, setup

      Check ASIC Control - browser tab timeout 
      AIDA MIDAS HTTPD server console log - attachment 3

      Appears to have restored ASIC settings 2024Dec13-17.02.45 saved yesterday
    
      aida10 ASICs #1 & #2 positive input, ASICs #3 & #4 negative input
      slow comparator 0xa (all p+n junction FEE64s and aida10), 0xf (n+n Ohmic FEE64s)

13:28 tar ASIC settings - attachment 4

[npg@aidas-gsi]$ cd /MIDAS/FEE_ASIC
[npg@aidas-gsi FEE_ASIC]$ tar cvf /tmp/FEE_ASIC.tar .

       System wide checks

       Sync ASIC clocks - attachment 5

       Clock, ADC calibration, WR decoder, FPGA timestamp, PLL checks - attachments 6-11
        all OK *except* aida02 WR decoder error

       WR timestamps OK - attachment 12
       FEE64 temps OK - attachment 13
       
13:45 Detector bias ON - attachment 14      

      BNC PB-5 pulser settings - attachment 15
      Pulser connected to all p+n junction FEE64s *except* aida10

      ADC, DISC, PAUSE and MBS correlation scaler stats - attachments 16-19
       aida02 rate significantly lower than yesterday - https://elog.gsi.de/despec/Implantation+Stack/8
       high rates observed for aida08, aida11 and aida14 - which are not connected to a DSSSD!

      per FEE64 Rate spectra - attachment 20

      per p+n junction FEE64 1.8.L spectra - attachment 21
       aida09 pulser peak width 56 ch FWHM = 39 keV FWHM
       consistent electronic noise for all p+n junction FEE64s (cabling+DSSSD)
       electronic noise of p+n junction FEE64s (cabling *only*) higher and more variable cf. https://elog.gsi.de/despec/Implantation+Stack/8 attachment 5

      per p+n junction FEE64 1.8.W spectra 20us FSR - attachments 22-23

      per n+n Ohmic FEE64 1.8.W spectra 20us FSR - attachment 24 

      WR timestamps OK - attachment 25

14:43 DAQ STOP
      Data transfer enabled
      Select Tape Server -> Next Run
      DAQ GO  data file R3

      Merger, Tape Server - attachments 26-27
       data transfer rate c. 900k data items/s cf c. 300k data items/s yesterday https://elog.gsi.de/despec/Implantation+Stack/8

16:45 DAQ STOP

      Data transfer disabled 

      Detector bias OFF

      FEE64 power OFF

Snout assembled for detector position and timing test.

The planned test is to use a BGO with a 22-Na source and the implantation stack to characterise the timing and position of back-to-back 511 keV events (proxy for mock beta decay event).

The implantation stack is assembled as follows:

Upstream ----> AIDA test frame (as a spacer) ----> AIDA DSSSD (3208-3/3208-21/3208-22, Upstream AIDA used in S100 & S181, April 2024) ----> bPlast (Downstream bPlast) ----> BB7 (mounted in test frame connected to AIDA adaptor) ----> Downstream

The AIDA DSSSD condition seems to be the same as when it was dismounted after S181 and it, apart from some specks of dust no bond wires appear to be broken to the naked eye.

BGO signals appear on the scope with a 22-Na source but the response is quite messy.

17:36

MSL type BB18(DS)-1000 24cm  x 8cm DSSSD upstream position within snout using 8x upstream (23") ribbon cables 

MSL type BB(DS)-1000 positioned downstream of downstream bPlast within snout using 1x downstream (29") ribbon cable. For BB7 'isolated' Right Coupler Kapton PCB replaced by unmodified Right Coupler Kapton PCB.

BB7 connected to aida07, sitting in a cardboard box

Update Tcl/Tml files in ASIC, ASIC4 and sys.tml frm PJCS email to allow setting per-ASIC polarity on FEE64
Restart MIDAS@8015

Power on all FEEs

Note nnrpi is not responding to ssh... MP investigates if it ahs been unplugged
 No, but a powercycle worked and fixed it

See error: /MIDAS/FEE_ASIC/aida06/ASICs.txt  not found, create the folders

We see some data in the L spectra, and changing the settings from one ASIC seems to work properly

Stopped for CC/MP to determine the which ASICs correspond to p+n and n+n

Follow up: Alpha data overnight or source?

Offline analysis of S100 data files R21_0 - R21_99 (162Eu setting)

first WR ts
First timestamp of R21_0 0x17CA09154AE3E636

Epoch converter says ...

GMT: Saturday, April 27, 2024 4:36:35.223 AM
Your time zone: Saturday, April 27, 2024 5:36:35.223 AM GMT+01:00 DST

last WR ts
First timestamp of R21_100 0x17CA16C1904150CE

GMT: Saturday, April 27, 2024 8:47:08.772 AM
Your time zone: Saturday, April 27, 2024 9:47:08.772 AM GMT+01:00 DST


FEE64 configuration

FEE64   a b c 
      g       h
        d e f

         a  b  c  d  e  f  g  h
DSSSD#1 15  3 12  9  1  5  2  4
DSSSD#2 11  7 16 10 14 13  6  8

n+n Ohmic FEE64s 2, 4, 6, 8

Data analysis assumes

- all LEC ADC data channels with valid ADC offset included (1012 of 1024 channels)
      LEC calibration ADC offset only

- no clustering

- no multiplex timestamp correction

- no p+n junction side - n+n Ohmic side correlation time gates

- FEE64 *not* DSSSD strip ordering

- hardware - slow comparator setting p+n junction FEE64s 100keV, n+n Ohmic FEE64s 150keV

- LEC energy difference +/-168keV

- HEC energy difference +/- 1.68GeV

- valid LEC events

   DSSSD #1
   p+n junction side multiplicity = 1 and n+n Ohmic side multiplicity = 1
   DSSSD #2 
   0 < p+n junction side multiplicity < 8 
   and
   0 < n+n Ohmic side multiplicity < 8 

   151keV < LEC energy < 1008keV
    to select candidate beta events and veto higher energy events e.g. light ions
    standalone analysis of AIDA data, no downstream veto detector

- valid HEC events
   p+n junction side multiplicity > 0 and n+n Ohmic side multiplicity > 0

  (x,y) strips corresponding to maximum energy
  p+n junction and n+n Ohmic side HEC 

- HEC veto 
   p+n junction side multiplicity > 0 or n+n Ohmic side multiplicity > 0

- per pixel implant-decay correlations

- end of event 
   difference in WR timestamp between successive ADC data items > 2500

Attachments 1-4
per DSSSD p+n junction - n+n Ohmic strip time difference for HEC and LEC events (2us/channel) linear and log scale

- observe large (> 32us) time differences (on log scale)

- range of time differences increases with multiplicity ( DSSSD#1 cf. DSSSD#2 LEC events)

- distribution of HEC time differences can probably be understood in terms of most/all channels of ASIC being active during HEC event with low LEC thresholds

- AIDA is a triggerless DAQ producing streams of ADC data items *not* events
   at high instantaneous rates when events are constructed they may become aggregated in time i.e. > 32us readout time of all channels of one ASIC

- To investigate impose additional end of event criterion 
   difference in first and last WR timestamp of event < 33us

Attachments 5-6
per DSSSD p+n junction - n+n Ohmic strip time difference for HEC and LEC events (2us/channel) linear and log scale

- blue original end of event criteria, cyan new end of event criteria

- as expected range of time differences is restricted to +/- 32us 

- observe somewhat higher fraction of events with low time differences
 
  DSSSD #1 10363098 of 16104322 (64%) events +/-2us 

  DSSSD #2 860454912 of 1766618199 (49%) events +/-2us

Attachment 7
per DSSSD p+n junction - n+n Ohmic strip time difference for LEC events - x-axis 2us/channel, y-axis 20keV /channel


Attachment 8 per FEE64 LEC data rate (Hz) 268ms/channel
Attachment 9 per FEE64 LEC data rate (Hz) 268ms/channel: 150keV < energy < 1500keV
Attachment 10 per FEE64 LEC data rate (Hz) 268ms/channel: energy > 1500keV

- observe high instantaneous rate on spill
- rate dominated by low energy (<1500keV) events
- rate of higher energy events dominated by on spill events i.e. light ions as expected
- significant deadtime on spill for n+n Ohmic FEE64s, low deadtime off spill
- deadtime low/zero for p+n junction FEE64s on/off spill

Attachment 11 per FEE64 LEC hit pattern: 150keV < energy < 1500keV
Attachment 12 per FEE64 LEC hit pattern: energy > 1500keV


Attachment 13 per FEE64 HEC data rate (Hz) 268ms/channel
Attachment 14 per FEE64 HEC data rate (Hz) 268ms/channel: 100MeV < energy < 1000MeV
Attachment 15 per FEE64 HEC data rate (Hz) 268ms/channel: energy > 1000MeV

- rate dominated by low energy (>1GeV) events
- all HEC events on spill as expected (note FEE64 #7 has a single hot channel which can be disabled in software)
- significant deadtime on spill for n+n Ohmic FEE64s, low deadtime off spill
- deadtime low/zero for p+n junction FEE64s on/off spill

Attachment 16 per DSSSD p+n junction versus n+n Ohmic LEC energy - x-axis & y-axis 20keV/channel

Attachment 17 per DSSSD p+n junction versus n+n Ohmic HEC energy - x-axis & y-axis 20MeV/channel

Attachment 18 per DSSSD p+n junction versus n+n Ohmic HEC strip hit pattern: all HEC events

Attachment 19 per DSSSD p+n junction versus n+n Ohmic HEC strip hit pattern
 DSSSD #1 ions stopped in DSSSD #1 i.e. DSSSD #2 HEC multiplicity = 0
 DSSSD #1 shows x-y gate used ( 270 < x < 370, 20 < y < 90 ) to identify 166Tb implants
 DSSSD #2 ions stopped in DSSSD #2 *and* in transmission (can establish which ions stop in DSSSD#2 from DSSSD#2 HEC energy versus DSSSD#1 HEC energy - see https://elog.ph.ed.ac.uk/DESPEC/672

Attachment 20

DSSSD#1 HEC energy (20MeV/channel) versus HEC-LEC dt (1s/channel)

DSSSD#1 LEC energy (20keV/channel) versus HEC-LEC dt (1s/channel)

DSSSD#1 HEC strip # versus HEC-LEC dt (1s/channel)

- Observe # events in every third channel is lower 
- Probably reflects implant-decay correlation livetime
  For example (choosing some numbers for illustrative purposes)
  on spill: HEC livetime 75%, LEC livetime 75% (FEE64 deadtime common for HEC and LEC data) => implant decay correlation livetime 56%
  off spill: HEC live time 75%, LEC livetime 100% =>  implant decay correlation livetime 75%
- Observe 'hot' x channels 315, 318, 321, 324 - disabled for further analysis
- Do not observe any 'hot' y channels 


Attachments 21 & 22

DSSSD#1 per pixel HEC-LEC time (1s/channel): x,y,z gated to select 166Tb events

Naive (parent-daughter decay only, flat background) fit for data t=0-26s ( t1/2 = 27.1(3)s )

Fit ignores data for t=0, 3, 6, 10, 13, 16, 19, 22s to avoid bias of differences in implant-decay correlation deadtime

Suggestion of structure at c. 30s period? Does this reflect spill stucture? 10x spill cycles (30s), 9s spill off, ... etc

Sum of x,y,z gated HEC events (s2112 - see attachment 19) = 670441

Elapsed time of dataset 4h11m = 15060s
# pixels = 100 x 70 = 7000
=> # x,y,z gated HEC events per pixel = 670441/7000/15060 = 0.0064/s or mean time between x,y,z gated HEC event = 157s (estimate needs to be corrected for HEC deadtime)

Sum of implant decay correlations (s2220 - see attachment 21) t=0-150s = 273508 - flat background estimated as 150 x 500 = 75000 = 198508

=> efficiency c. 30% (presumably low due to implant-decay deadtime, LEC multiplicity, per pixel correlations and no clustering)


Summary

$64,000 question - what is the origin of the high instantaneous rate on spill  for DSSSD#1 ? On my to do list.


Attachment 23

LEC multiplicity with/without HEC data in event

per DSSSD LEC p+n junction multiplicity versus n+n Ohmic multiplicity
per DSSSD LEC p+n junction multiplicity versus n+n Ohmic multiplicity z_hec=1 and z_hec=2


With HEC data

DSSSD#1 p+n junction multiplicity ~ 17, n+n Ohmic multiplicity ~28
DSSSD#2 p+n junction multiplicity ~ 40, n+n Ohmic multiplicity ~23

Assume 200Hz HEC events => DSSSD#1 LEC rate = 200 x ( 17 + 28 ) => 9k LEC data items cf. >100k LEC data items (attachments 8 & 13)

i.e. not due to HEC events








 
 


 







   

Anydesk restarted remotely per https://elog.ph.ed.ac.uk/CARME/489

Offline analysis of data files S505/R5_780 - R5_814 (corresponding to MBS data files 73-74) 

Can find an analysis of alpha background runs at RIBF, RIKEN for comparison at https://elog.ph.ed.ac.uk/AIDA/816

Beam off - background runs without sources

MBS 73 27.6.22 09:33-11:33 CEST https://elog.gsi.de/despec/S505/204

MBS 74 27.6.22 11:34-13:34 CEST https://elog.gsi.de/despec/S505/206

MBS 75 27.6.22 13:35-16:29 CEST https://elog.gsi.de/despec/S505/209

ADC offsets per https://elog.ph.ed.ac.uk/DESPEC/556

FEE64 configuration

FEE64   a b c d
DSSSD#1 3 4 1 2
DSSSD#2 7 8 5 6

p+n junction FE64s odd numbered


Data analysis assumes

- all LEC ADC data channels with valid ADC offset included (474 of 512 channels)
- no clustering
- no p+n junction side - n+n Ohmic side correlation time gates
- valid LEC events
   0 < p+n junction side multiplicity < 8 
   and
   0 < n+n Ohmic side multiplicity < 8 


Attachments 1-2 - per DSSSD p+n versus n+n multiplicity

Attachment 3 - per DSSSD x versus y

Attachments 4-5 - per DSSSD p+n versus n+n energy (20keV/channel nominal)
                  all combinations of per DSSSD p+n junction and n+n Ohmic energies 
                  with projection of data within window onto x and y axes

                  too many events for natural (U decay series) background
                  off leading diagonal correlations anomalous
                  transverse width of leading diagonal correlation wider than expected - ADC offsets OK?
                 

Attachment 6 - per FEE64 WR timestamp (32.768us/channel)
               FEE64 sync test using pulser data - looks OK

Attachments 7-14 - per FEE64 ADC spectra (5.6keV/channel nominal)
                   note common x/y scale - pulser peak height proxy for peak width

per FEE64 1.8.L pulser peak widths (ch FWHM)

1 11.43
2 16.58
3 12.52
4 17.54
5 9.10
6 12.22
7 17.03
8 16.09

3 of 4 p+n junction FEE64 good (<70keV), 1 of 4 n+n Ohmic FEE64 good - all others < 100keV
Pulser peak indicates noise/gain/offset stable throughout background runs


Attachments 15-22 - per FEE64 ADC spectra (5.6kleV/channel nominal)
                    observe broad peak-like structures (c. 2.8MeV) in first channel of most ASICs? 

Attachment 23 per DSSSD p+n versus n+n energy (20keV/channel nominal)
              valid LEC events
              p+n junction side multiplicity = 1 n+n Ohmic side multiplicity = 1

Attachment 24 p+n FEE64 #0 energy versus each of n+n FEE64s (#1, #3, #5 and #7) energies (20keV/channel nominal)
              valid LEC events
              p+n junction side multiplicity = 1 n+n Ohmic side multiplicity = 1

Attachments 23 & 24 do not unambiguously identify which FEE64s are attached to which DSSSD