AIDA GELINA BRIKEN nToF CRIB ISOLDE CIRCE nTOFCapture DESPEC DTAS EDI_PSA 179Ta CARME StellarModelling DCF K40
  AIDA, Page 4 of 46  ELOG logo
ID Date Author Subjectdown
  308   Sat Jun 11 15:48:49 2016 TD[How To] Monitor Pause-Resume Times
The basic GREAT data format analyser will report per FEE cumulative
pause-resume times which should be << timestamp elapsed time (which
is time taken to write the data file analysed).

aidas1> ~/td/GREAT/analyser2 /TapeData/NP1512/AIDA40_52
 *** GREAT format 3.2.0 analyser - TD - May 2014
 *** ERROR: READ I/O error:       5002
                   blocks:      32000
          ADC data format:  147698907 (  924090.7 Hz)
        Other data format:  113421093 (  709628.6 Hz)
 Sample trace data format:          0 (       0.0 Hz)
         Undefined format:          0 (       0.0 Hz)
   Other data format type:      PAUSE:       6592 (      41.2 Hz)
                               RESUME:       6592 (      41.2 Hz)
                              SYNC100:      60971 (     381.5 Hz)
                           FEE64 disc:  112649552 (  704801.4 Hz)
                             MBS info:     697386 (    4363.3 Hz)
                           Other info:          0 (       0.0 Hz)

   ADC data range bit set:     312853 (    1957.4 Hz)

                Timewarps:        ADC:          0 (       0.0 Hz)
                                PAUSE:          0 (       0.0 Hz)
                               RESUME:          0 (       0.0 Hz)
                              SYNC100:          1 (       0.0 Hz)
                           FEE64 disc:          0 (       0.0 Hz)
                             MBS info:          0 (       0.0 Hz)
                            Undefined:          0 (       0.0 Hz)
                         Sample trace:          0 (       0.0 Hz)

 Timestamp elapsed time:      159.832 s
 FEE module #:   1 elapsed dead time       0.030 s
 FEE module #:   2 elapsed dead time       0.291 s
 FEE module #:   3 elapsed dead time       0.029 s
 FEE module #:   4 elapsed dead time       0.000 s
 FEE module #:   5 elapsed dead time       0.132 s
 FEE module #:   6 elapsed dead time       0.078 s
 FEE module #:   7 elapsed dead time       0.000 s
 FEE module #:   8 elapsed dead time       0.000 s
 FEE module #:   9 elapsed dead time       0.041 s
 FEE module #:  10 elapsed dead time       0.000 s
 FEE module #:  11 elapsed dead time       0.099 s
 FEE module #:  12 elapsed dead time       0.038 s
 FEE module #:  13 elapsed dead time       0.000 s
 FEE module #:  14 elapsed dead time       0.008 s
 FEE module #:  15 elapsed dead time       0.074 s
 FEE module #:  16 elapsed dead time       1.036 s
 FEE module #:  17 elapsed dead time       0.000 s
 FEE module #:  18 elapsed dead time       0.026 s
 FEE module #:  19 elapsed dead time       0.000 s
 FEE module #:  20 elapsed dead time       0.247 s
 FEE module #:  21 elapsed dead time       0.421 s
 FEE module #:  22 elapsed dead time       0.024 s
 FEE module #:  23 elapsed dead time       1.628 s
 FEE module #:  24 elapsed dead time       0.493 s
 FEE module #:  25 elapsed dead time       0.000 s
 FEE module #:  26 elapsed dead time       0.000 s
 FEE module #:  27 elapsed dead time       0.000 s
 FEE module #:  28 elapsed dead time       0.000 s
 FEE module #:  29 elapsed dead time       0.000 s
 FEE module #:  30 elapsed dead time       0.000 s
 FEE module #:  31 elapsed dead time       0.000 s
 FEE module #:  32 elapsed dead time       0.000 s

 *** Program elapsed time:   26.523s ( 1206.480 blocks/s,  75.405 Mb/s)
  211   Thu May 5 08:47:49 2016 TD[How To] Mask Fast Discriminators
From the 'AIDA Control' tab select 'Discriminator control'

From the 'Discriminator controls' tab 

     select 'Reload'
     select FEE64 required
     select (or deselect) 'Act on ALL FEE64 modules?' as required
     select ASIC channel(s) to mask

The current default value (set by AIDA Settings) is 0x0 (no fast discriminator masks defined)

ASIC channels commonly masked include #2 (AS0 01) and #55 (AS3 06)
  25   Wed Jan 28 16:19:05 2015 Patrick Coleman-Smith[How To] Loading new firmware into a FEE64

Log into the FEE64 module using telnet.

use root

enter =>  /usr/sbin/flash_unlock /dev/mtd2

enter => /usr/sbin/flashcp -v /MIDAS/Aida/< filename>.bin /dev/mtd2
 
then logout when done.
 
The flashcp program will erase the existing contents, then write the new file and finally verify the result.
Power cycle the FEE64 will load the new firmware.
 
The -v flag after the flashcp command ensures you can see what is going on.
 
There is a script in the /MIDAS/Aida directory called FlashPgm.csh which contains these commands and is used by the global re-programming command from the "Expert" menu on the RunControl page.
 
If you wish to program a lot of modules then alter the filename  in the flashcp command in this script.
 
Please let me know if you see errors in this description.
 
  227   Sat May 14 11:27:09 2016 AE, VP[How To] DAQ correlation monitor (June16 campaign)
The program for online monitoring the correlation of the DAQ systems (AIDA-EURICA-BigRIPS) through a common scaler is SyncCheck (J. 
Agramunt). 

The code runs in the d05 server, receiving data transferred to a DataSink from each of the individual DAQs. The data transfer is 
done with the DataRelayFilter code for AIDA (AE), and the euricatssender and ribftssender (Baba-san) codes for EURICA and RIBFdaq, 
respectively.  

The attached screenshots show how to setup these programs. Follow these steps:

1) Log in to d05 as user 'aida'. Start an instance of the DataSink code with option -i 3 (3 data stream, which will use ports 10305 
to 10307). The code is saved in /home/aida/DataPackage/DataSink/Linux64

2) In the d05 server start the following codes: euricatssender (in /home/aida/ribfts/euricatssender/ directory), and ribftssender 
(in /home/aida/ribfts/ribftssender/ directory). If you give the codes dummy command line option (e.g. -X) the value of transferred 
timestamps will be printed to screen as diagnostics.

3) In the AIDA computer (aidas1), start the DataRelayFilter program (will work from any directory). As command line arguments 
provide the IP address of d05, and the TCP port and id of the data stream for the DataSink program: DataRelayFilter -n 10.32.0.12 -
p 10307 -I 2

Only the master FEE will produce correlation scalar items (?). The code has as default NNAIDA5 for the module where to search for the Corr Scaler
items; if this has to be changed use command line option -m X (where X is NNAIDAX number for new master FEE)

4) Back in the d05 server start the SyncCheck program, in the directory /home/aida/SyncCheck/. You can give as an argument the ID 
of the Master data stream for the synchronization check, through "-M ID" (should be done if one of the three data streams is down). 
For example "SynCheck -M 2" will use AIDA as the master timestamp.

5) Perform a manual correlation reset request to synchronize the value of the correlation scaler in all three DAQs. This is done with the 
button 'Force Correlation Reset' of the AIDA "Correlation Status & Control" webpage (attachment 2), which can be accessed from the MIDAS web-
based control of AIDA.

The SyncCheck code will display a few spectra for onine monitoring of DAQ correlation (attachment 3, shown only with AIDA and EURICA running). 
A peak will appear showing the offset in the correlation scaler between the different DAQs. The counts in the peak should increase 
continuously, and its position should not change. If it doesn't, try sending a Correlation Reset signal (step 5). If this does not fix the 
monitor, report a correlation error! 

Further information on the scheme for data synchronization is here: 
https://elog.ph.ed.ac.uk/BRIKEN/6
https://elog.ph.ed.ac.uk/BRIKEN/5
  189   Thu Apr 28 07:42:11 2016 TD[How To] Change the AIDA Acquisition Server Configuration
Edit the file /MIDAS/config/TclHttpd/aidas1/startup.tcl and change the definition of variables
PACQSERVERS, NACQSERVERS, ACQSERVERS (respectively p+n junction strip FEE64s, n+n ohmic strip
FEE64s, and all FEE64s) for example,
     
    variable PACQSERVERS; set PACQSERVERS { nnaida5 nnaida6 nnaida9 nnaida10}
    variable NACQSERVERS; set NACQSERVERS { nnaida3 nnaida4 nnaida7 nnaida8}
    
    lappend ACQSERVERS nnaida3
    lappend ACQSERVERS nnaida4
    lappend ACQSERVERS nnaida5
    lappend ACQSERVERS nnaida6
    lappend ACQSERVERS nnaida7
    lappend ACQSERVERS nnaida8
    lappend ACQSERVERS nnaida9
    lappend ACQSERVERS nnaida10

You will need to close the web browser running MIDAS, restart the 'Httpd for Acquisition' server,
restart the web browser and start the MIDAS DAQ session.

On the 'Run Control' page, toggle 'Act on ALL Data Acquisition Servers' and select 'Reload' - the
revised acquisition server list should now be shown.
  26   Thu Jan 29 15:57:01 2015 Patrick Coleman-Smith[How To] AIDA power supply alteration document

 I've added the power supply change document.

Please have a look and let me know if it requires further clarification.

I have ordered some plastic "pot twiddlers".

 

I have run a simple test with the four FEE64 here + detector.

The sequence was :- 

Run the system with filtered PSU and record FWHM for 1.4.L for each of the four FEE64 boards.

Replace the PSU with a standard but with outputs set as per the attachement.

Results were approx 1.5 x worse.

Replace filtered PSU..... back as expected.

Addition: For Filter PSU only :- Set +5v to +6v when the FEE64 is not attached.

This is required as the extar impedance of the filter drops the voltage too much by the time it reaches the FEE64.

  27   Fri Jan 30 13:02:35 2015 Alfredo Estrade[Data] R61 (207Bi source) and R62-R65 (pulser walk-through)
Jan 22, 2015

R61: 207Bi source spectra accumulated during one afternoon. Same settings as in R49 (alpha background run, 
elog entry 23) 

  + pulser: 0.5V, split and one of the signals inverted, and f=100 Hz.
  + threshold for slow comparators:
	- Eth(nnaida11)= 0x16
	- Eth(nnaida12)= 0x20
	- Eth(nnaida13)= 0x40
	- Eth(nnaida14)= 0x16

R62-R65: short runs with different amplitude for pulser (source still in):

 + R62: pulser @ 0.75 V
 + R63: pulser @ 1.00 V
 + R64: pulser @ 0.30 V
 + R65: pulser @ 0.18 V

R61 provides another point @ 0.5. V.


Raw data files saved in external drive (/media/data/TapeData/Test100/), and in UoEdinburgh disk space 
(/Disk/ds-sopa-personal/aestrade/data/AIDA/):

-rw------- 1 aestrade root 1177685085 Jan 21 16:55 R61_0.gz
-rw------- 1 aestrade root 1175087265 Jan 21 16:57 R61_1.gz
-rw------- 1 aestrade root 1176655505 Jan 21 17:00 R61_2.gz
-rw------- 1 aestrade root 1173848081 Jan 21 17:02 R61_3.gz
-rw------- 1 aestrade root 1180888194 Jan 21 17:05 R61_4.gz
-rw------- 1 aestrade root  168022642 Jan 21 17:05 R61_5.gz
-rw------- 1 aestrade root   77074827 Jan 22 13:12 R62_0.gz
-rw------- 1 aestrade root   45584289 Jan 22 13:12 R63_0.gz
-rw------- 1 aestrade root   42043231 Jan 22 13:12 R64_0.gz
-rw------- 1 aestrade root   41005241 Jan 22 13:12 R65_0.gz
  112   Tue Jul 14 18:06:54 2015 AE, CG[Data Analysis] Correlation Scaler timestamp in PID data (go4_30**.root)
The attached plots show the time-stamp data in the EURICA files with PID information (EventInfo.timestamp). The
timestamp value should correspond to the correlation scaler included as info_code==8 in AIDA. 

The plots show time-stamp vs entry number in the TTree of the Root file, with the events in groups of about 10
*.root files counted consecutively. To map entry-number to data file use informatino of number of entries per
file in the lines bellow (output of analysis script). NOTE: label for plots in right colume is wrong, trigger
type=3 (pulser) in stead of 2.

The final three plots (pulser_dts_go4_3022*.png) show the time difference between two sequential data points of a
given trigger type (fBit==2 or 3). The value that would correspond to the external scaler (fBit==3) has a peak at
about delta(ts)= 1.7 sec, but also a lot of events with a distribution centered around a smaller value of
delta(ts)~ 10 msec! One can also see the deadtime at about 300 usec at a smaller scale. The units for the
time-stamp are 1-ns.

A plot of a similar distribution for the data in AIDA shows that the peak of the correlation scaler has, in this
case, a very narrow distribution, with a frequency of ~43.5e6 x 40 ns (would agree with Go4 data from EURICA).

When scanning the files the analysis script (attached) skips a given number of entries (~100) to speed up the
analysis.


Number of entries in PID tree= 2592193 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3002.root
(accumulated= 2592193)
Number of entries in PID tree= 2570084 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3003.root
(accumulated= 5162277)
Number of entries in PID tree= 676355 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3004.root
(accumulated= 5838632)
Number of entries in PID tree= 2582203 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3005.root
(accumulated= 8420835)
Number of entries in PID tree= 2602541 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3006.root
(accumulated= 11023376)
Number of entries in PID tree= 2602681 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3007.root
(accumulated= 13626057)
Number of entries in PID tree= 2605726 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3008.root
(accumulated= 16231783)
Number of entries in PID tree= 2606264 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3009.root
(accumulated= 18838047)
Number of entries in PID tree= 2603841 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3010.root
(accumulated= 21441888)
Number of entries in PID tree= 2599770 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3011.root
(accumulated= 24041658)

Number of entries in PID tree= 2601002 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3012.root
(accumulated= 2601002)
Number of entries in PID tree= 2598946 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3013.root
(accumulated= 5199948)
Number of entries in PID tree= 2596582 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3014.root
(accumulated= 7796530)
Number of entries in PID tree= 2596506 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3015.root
(accumulated= 10393036)
Number of entries in PID tree= 2588772 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3016.root
(accumulated= 12981808)
Number of entries in PID tree= 2583160 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3017.root
(accumulated= 15564968)
Number of entries in PID tree= 2589905 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3018.root
(accumulated= 18154873)
Number of entries in PID tree= 2581979 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3019.root
(accumulated= 20736852)
Number of entries in PID tree= 2582410 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3020.root
(accumulated= 23319262)
Number of entries in PID tree= 2582181 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3021.root
(accumulated= 25901443)

Number of entries in PID tree= 2580798 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3022.root
(accumulated= 2580798)
Number of entries in PID tree= 2580669 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3023.root
(accumulated= 5161467)
Number of entries in PID tree= 2583346 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3024.root
(accumulated= 7744813)
Number of entries in PID tree= 2645673 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3025.root
(accumulated= 10390486)
Number of entries in PID tree= 1984963 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3026.root
(accumulated= 12375449)
Number of entries in PID tree= 2629453 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3027.root
(accumulated= 15004902)
Number of entries in PID tree= 2636095 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3028.root
(accumulated= 17640997)
Number of entries in PID tree= 2639067 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3029.root
(accumulated= 20280064)
Number of entries in PID tree= 2643485 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3030.root
(accumulated= 22923549)
Number of entries in PID tree= 2644457 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3031.root
(accumulated= 25568006)

Number of entries in PID tree= 2643522 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3032.root
(accumulated= 2643522)
Number of entries in PID tree= 2641053 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3033.root
(accumulated= 5284575)
Number of entries in PID tree= 2637280 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3034.root
(accumulated= 7921855)
Number of entries in PID tree= 2627822 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3035.root
(accumulated= 10549677)
Number of entries in PID tree= 2637326 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3036.root
(accumulated= 13187003)
Number of entries in PID tree= 2635601 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3037.root
(accumulated= 15822604)
Number of entries in PID tree= 2606912 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3038.root
(accumulated= 18429516)
Number of entries in PID tree= 2635101 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3039.root
(accumulated= 21064617)
Number of entries in PID tree= 2634932 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3040.root
(accumulated= 23699549)
Number of entries in PID tree= 2633415 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3041.root
(accumulated= 26332964)

Number of entries in PID tree= 2633892 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3042.root
(accumulated= 2633892)
Number of entries in PID tree= 2640264 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3043.root
(accumulated= 5274156)
Number of entries in PID tree= 2612700 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3044.root
(accumulated= 7886856)
Number of entries in PID tree= 2632762 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3045.root
(accumulated= 10519618)
Number of entries in PID tree= 1962430 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3046.root
(accumulated= 12482048)
Number of entries in PID tree= 2611491 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3047.root
(accumulated= 15093539)
Number of entries in PID tree= 2649244 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3048.root
(accumulated= 17742783)
Number of entries in PID tree= 2679210 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3049.root
(accumulated= 20421993)
Number of entries in PID tree= 518667 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_3050.root
(accumulated= 20940660)
  115   Fri Jul 17 17:28:35 2015 AE[Data Analysis] Correlation Scaler 100Kr data (go4_30**.root)
Plots of corr-scaler vs event number in Root files for 100Kr(?) setting: go4_40XX.root.

Same script, and plot description, as in the ELOG entry for go4_30XX.root files: https://elog.ph.ed.ac.uk/AIDA/112

These are accumulated events for each run (to map event# -> run number):

Number of entries in PID tree= 2606359 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4001.root
(accumulated= 2606359)
Number of entries in PID tree= 2609120 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4002.root
(accumulated= 5215479)
Number of entries in PID tree= 2607343 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4003.root
(accumulated= 7822822)
Number of entries in PID tree= 2603241 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4004.root
(accumulated= 10426063)
Number of entries in PID tree= 2602664 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4005.root
(accumulated= 13028727)
Number of entries in PID tree= 2597915 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4006.root
(accumulated= 15626642)
Number of entries in PID tree= 2606679 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4007.root
(accumulated= 18233321)
Number of entries in PID tree= 2604197 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4008.root
(accumulated= 20837518)
Number of entries in PID tree= 2604402 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4009.root
(accumulated= 23441920)
Number of entries in PID tree= 2604980 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4010.root
(accumulated= 26046900)

Number of entries in PID tree= 2608074 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4011.root
(accumulated= 2608074)
Number of entries in PID tree= 2609093 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4012.root
(accumulated= 5217167)
Number of entries in PID tree= 2608080 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4013.root
(accumulated= 7825247)
Number of entries in PID tree= 2605479 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4014.root
(accumulated= 10430726)
Number of entries in PID tree= 2598820 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4015.root
(accumulated= 13029546)
Number of entries in PID tree= 2603066 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4016.root
(accumulated= 15632612)
Number of entries in PID tree= 2605692 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4017.root
(accumulated= 18238304)
Number of entries in PID tree= 2611812 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4018.root
(accumulated= 20850116)
Number of entries in PID tree= 2607623 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4019.root
(accumulated= 23457739)
Number of entries in PID tree= 2607970 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4020.root
(accumulated= 26065709)

Number of entries in PID tree= 2609207 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4021.root
(accumulated= 2609207)
Number of entries in PID tree= 2602567 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4022.root
(accumulated= 5211774)
Number of entries in PID tree= 2613624 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4023.root
(accumulated= 7825398)
Number of entries in PID tree= 2612418 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4024.root
(accumulated= 10437816)
Number of entries in PID tree= 2615720 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4025.root
(accumulated= 13053536)
Number of entries in PID tree= 2615051 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4026.root
(accumulated= 15668587)
Number of entries in PID tree= 2610490 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4027.root
(accumulated= 18279077)
Number of entries in PID tree= 2608960 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4028.root
(accumulated= 20888037)
Number of entries in PID tree= 2599656 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4029.root
(accumulated= 23487693)
Number of entries in PID tree= 2611283 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4030.root
(accumulated= 26098976)

Number of entries in PID tree= 2597833 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4031.root
(accumulated= 2597833)
Number of entries in PID tree= 2574550 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4032.root
(accumulated= 5172383)
Number of entries in PID tree= 2592651 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4033.root
(accumulated= 7765034)
Number of entries in PID tree= 2598995 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4034.root
(accumulated= 10364029)
Number of entries in PID tree= 2605854 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4035.root
(accumulated= 12969883)
Number of entries in PID tree= 2603045 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4036.root
(accumulated= 15572928)
Number of entries in PID tree= 2596530 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4037.root
(accumulated= 18169458)
Number of entries in PID tree= 2582396 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4038.root
(accumulated= 20751854)
Number of entries in PID tree= 2573176 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4039.root
(accumulated= 23325030)
Number of entries in PID tree= 2579368 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4040.root
(accumulated= 25904398)

Number of entries in PID tree= 2576076 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4041.root
(accumulated= 2576076)
Number of entries in PID tree= 2571398 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4042.root
(accumulated= 5147474)
Number of entries in PID tree= 2561229 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4043.root
(accumulated= 7708703)
Number of entries in PID tree= 2555236 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4044.root
(accumulated= 10263939)
Number of entries in PID tree= 2550104 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4045.root
(accumulated= 12814043)
Number of entries in PID tree= 2617418 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4046.root
(accumulated= 15431461)
Number of entries in PID tree= 2625206 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4047.root
(accumulated= 18056667)
Number of entries in PID tree= 2619409 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4048.root
(accumulated= 20676076)
Number of entries in PID tree= 1540255 for file /Disk/ds-sopa-group/np/RIKEN/May2015/PID_data/go4_4049.root
(accumulated= 22216331)
  23   Thu Jan 22 14:26:10 2015 Alfredo and Tom[DATA] R49: alpha background radioactivity
Jan20-21, 2015


R49_* are a set of files corresponding to an overnight background measurement, with goal of detecting alphas
from uranium decay chain contaminants.

The settings of ASICs are attached as a screenshot. The low comparator thresholds are (see previous entry):
 nnaida#11= 0x16
 nnaida#12= 0x40 
 nnaida#13= 0x20
 nnaida#14= 0x16

For a significant fraction of the measurement, NNAIDA12 and NNAIDA13 were not generating good data. We 
didn't
invest much time in solving the issue, as it's recurrent problem with NNAIDA12, but it seems some ASICS went
back to normal behavior overnight.

Due to limited storage space, data in external drive (/media/data/TapeData/Test100/), and backued up 
temporarly
in Edinburhg (/Disk/ds-sopa-personal/aestrade/data/AIDA/).

A pulser walkthrough for this setting is available in runs R61-R65 (see next elog entry).



++ DATA ANALYSIS ++

A fraction of the runs (R49_1, R40_10-14) were analysed with the 'beta' version of the Root sort code for 
event
reconstruction (/homes/npg/AIDAsort/). The code creates events from data bits that fall within a window of
50usec, and included the additional requirement that the calibrated energy of each ADC hit should be E>1500 
keV.

Output from Root sort code saved here:

aestrade: AIDA $ pwd
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA
aestrade: AIDA $ ls R49_alpha_bckgr*
R49_alpha_bckgr_10_calib_log.txt  R49_alpha_bckgr_13_calib.root
R49_alpha_bckgr_10_calib.root     R49_alpha_bckgr_13_event_log.txt
R49_alpha_bckgr_10_event_log.txt  R49_alpha_bckgr_13_event.root
R49_alpha_bckgr_10_event.root     R49_alpha_bckgr_14_calib_log.txt
R49_alpha_bckgr_11_calib_log.txt  R49_alpha_bckgr_14_calib.root
R49_alpha_bckgr_11_calib.root     R49_alpha_bckgr_14_event_log.txt
R49_alpha_bckgr_11_event_log.txt  R49_alpha_bckgr_14_event.root
R49_alpha_bckgr_11_event.root     R49_alpha_bckgr1_calib_log.txt
R49_alpha_bckgr_12_calib_log.txt  R49_alpha_bckgr1_calib.root
R49_alpha_bckgr_12_calib.root     R49_alpha_bckgr1_event_log.txt
R49_alpha_bckgr_12_event_log.txt  R49_alpha_bckgr1_event.root
R49_alpha_bckgr_12_event.root     R49_alpha_bckgr1_sort_log.txt
R49_alpha_bckgr_13_calib_log.txt  R49_alpha_bckgr1_sort.root

A few plots from these data:

R49few_a_bckgrnd_multiplicity.png: Shows the multiplicity of reconstructed events. Peaks corresponding to
multiples of 64 are clear from pulser (64 ch/asic, although one FEE has some channels off so peaks shifted).
There is also peak at low multiplicity where gate to search for events can be placed. The events with very 
high
multiplicity indicate the time window used is too large, so we get random coincidences or high count from 
noisy
channels. The lower plots show how the energy sum increases linearly with the multiplicity of the event

R49few_a_bckgrnd_xy.png: Plots for the calculated mean strip for hits on each side (<x>: nnaida#11 and #12, 
<y>:
nnaida#13 and #14). The different plots have different condition applied. Top left only requires 
multiplicity on
x and y greater than zero (i.e., a hit for each side). The others require low multiplicity, or low spread of 
the
timestamp of the hits included (spread dts<10usec), and also mask out hits with x value of 18 or 101 (very 
high
count channels)

R49few_a_bckgrnd_dt_event.png: The difference of the time-stamp for hits with lowest and highest time-stamp
within each event. 50 usec is the event window considered (so highest possible value). Note that events with
multiplicity 2 (1 hit in x, and 1 hit in y) have almost exclusively a spread of very few clock cycles.

R49few_a_bckgrnd_EfEb.png: Energy front vs energy back spectra, with some of the conditions described above
(e.g. low multiplicity, or multi=2, low spread in time-stamp). All have hits with x=78 and 102 excluded. The
most clean spectra is top-right (one hit in x, one hit in y), but shows only a couple of hits with good 
energy
in both sides.
  113   Thu Jul 16 15:10:34 2015 Patrick Coleman-Smith[DAQ and VHDL] Changes to the Discriminator Information data item

 I have attached a document describing the new format of the Discriminator Information data item used in Version 8

  28   Fri Jan 30 15:27:35 2015 Alfredo Estrade[Analysis] 207Bi source (R61): check of monitor spectra
A first look at the data from the 207Bi source (run described in previous elog entry, ID 27)

The main conclusions are (see description of spectra further bellow):

- NNAIDA11 and NNAIDA13 were running stable, even though NNAIDA11 had one channel with very high rate. 
NNAIDA12 and 14 were running unstably with frequent instances of Pause/Resume. A possible explanation is 
their higher data rates (due to a bad channel and noise, respectively).

- I think using only a window in time will not be sufficient to identify electron signals in the data. 
This is a particular issue for the data of NNAIDA14, where there is a high noise and a energy threshold, 
or some more ingenious condition, is likely required.


Plots were generated with the script in /Home/aestrade/AIDA/analysis/loopAIDAsort.cpp

Only a fraction of the 207Bi data was processed (corresponding to file R62_2). 


+ Distribution of time-stamps

R61part_ts_dist_adc_hit.png: The spectra show the difference between the 
time-stamp of a given ADC hit (ts_i) and the time-stamp of subsequent ADC 
hits (ts_i+n):

	Delta ts(i+n,i) = ts_(i+n) - ts(i)

So the first plot, for Delta ts(i+1,i), is the difference between each ADC 
hit and the next ADC hit. The second plot is the ts difference between each 
ADC hit and the second to next ADC hit, and so on... 

The data mixes the spectra for all FEE cards and all ADC channels. One can 
still see a clear structure with a peak at low values of Delta ts, and then 
a second distribution up to Delta ts= 30*n usec. These is the time it takes 
to loop through all 16 channels of the ADC (2 usec/channel), so is likely 
the distribution generated by one channel is firing at a very high rate.

I'll make similar plots with conditions to mask out noisy channels and/or 
pulser events to look for a value of the coincidence time-window to use to 
reconstruct events.

+ Rates

R61part_rates.png: the spectra shows various rates (in Hz) as a function of 
run time and of channel. The plots on the top are the rate of ADC hits (for 
low energy range) of each FEE module, and one showing the rate of ADC hits 
for the high energy range in all modules combined. The bottom row shows rate 
per channel, and the rate of Information type hits.

some conclusions: NNAIDA11 and 13 show a flat rate, and as will be seen from other plots are very stable 
during the run. NNAIDA11 has a larger rate than 13, but the difference is mostly due to a very high-rate 
channel; the rate in most channels is consistent with a 100 Hz pulser for both.

NNAIDA12 and 14 show the largest rate that can peak at 35kHz, and looks quite unstable. These modules also 
have a choppy run of the DAQ (many Pause/Resume). NNAIDA11 actually has similar rate to NNAIDA12 and 14, 
but is still stable.

Both NNAIDA11 and 12 have one channel wiht very high rate compared to the 
rest (rather than unusually noisy channel, could it be one that is always 
above the threshold of the slow discriminator?).


+ ADC Rate with fine granularity

R61part_t1_hits_ts_adc.png: These spectra show the ADC hits (low range) vs time but with a higher binning 
of the data (1 ms/bin). The one channel with a very high rate in NNAIDA11 and 12 is seen in red. Also that 
the data readout from NNAIDA12 and 14 is frequently halted by Pause/Resume signals. 

R61part_t1_hits_ts_adc_zoom.png: The second file hast the same spectra but zoomed in a narrow time window, 
and one can see the hits from the pulser 10 ms appart (as vertial lines with hits in all channels for 2D 
spectra). In between the pulser signals, as hits in individual channels, are hits from the source or from 
noise. For NNAIDA14 this white noise was very high, so at the binning of 1ms/bin this spectra there are 
many channels with hits in each time bin. I think it will be difficult to identify electron events from 
such spectra using only a time window as requirement for coincidence. 


+ Info Codes Rates

R61part_t1_hits_ts_info.png : The spectra show the rates of information words. The first plots are again 
for a narrow section of the run (same as previous spectra). One can see the frequent sequence of 
Pause/Resume for NNAIDA12 and 14. Also note discriminator data and ADC(high range) hits only come for 
NNAIDA12 (we used very high value for discriminator threshold).

R61part_ts_info_fee.png: The figure shows the distribution of the different information codes for each FEE 
module, but now for the full lenght of the run.



++ Sorted Root TTree fiels ++

All raw files of run R61 were processed with the 'beta' version of the Root 
sort code for event reconstruction (/homes/npg/AIDAsort/ in DL PC), but only 
up to the 'Calibration' step (no event reconstructino). 
R61_207Bi_2_sort.root used for above plots. 

Root tree saved here:

/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_0_calib.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_0_sort.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_1_calib.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_1_sort.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_2_calib.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_2_sort.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_3_calib.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_3_sort.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_4_calib.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_4_sort.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_5_calib.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_5_sort.root


A bug on the Root sort code was identified from this output: the code waits 
for a SYNC100 pulse from *each* FEE card to update their corresponding 
most-significant bits (MSB) for the timestamp, while one has to use *any* 
SYNC100 pulse to update the MSB of all FEE modules. As a consecuence, a 
(very small) fraction of the processed hits have the wrong time-stamp (off 
by bit 28).
  465   Wed Nov 23 14:50:59 2016 Patrick Coleman-Smith[ Info ] What does the System Wide Clock check mean when it fails.

The System Wide check called "Check Clock Status"  reads the status register from the FEE64 units in the system and compares the value of each bit against a template depending if the FEE64 is Master or not.

The bit fields have the following meaning :-

  1. clkd_ld1_pin. This is the "locked" status of the PLL in clock distribution chip LMK03200 #1. The clocks are used for the Waveform ADCs. ADCs 1 to 4 and FPGA Waveform decode logic.
  2. clkd_ld2_pin. This is the "locked" status of the PLL in clock distribution chip LMK03200 #2. The clocks are used for the Waveform ADCs. ADCs 5 to 8 and the Master SYNC PLL in the FPGA.
  3. aq_clock_locked. This is the "locked" status of the PLL in the FPGA. The clock is used for all data aquisition functions. If this isn't true ('1') then the module is not going to work as part of the system.
  4. sync_locked. This is the "locked" status of the PLL in the FPGA which provides a 200MHz clock to the SYNC pulse alignement logic. This is only used in the Master.
  5. to 31 read as '0' 

The System Wide Check will only report the state of bits 0 to 2 but by opening the "Local Controls" browser window the status value can be seen ( after a reload ) at offset 1.

 

  29   Mon Feb 9 11:52:52 2015 Patrick Coleman-Smith[ How To ] Integrating AIDA with other systems

 This document details how to integrate AIDA with other systems.

  1   Wed Sep 10 08:42:03 2014 Tom DavinsonWelcome to the AIDA Elog
The AIDA Elog is now operational and can be found at

https://elog.ph.ed.ac.uk/AIDA/
  49   Wed Feb 25 09:59:28 2015 CG, AEWeds 25th Feb progress

25/02/15

1200: Swapped out old green power switch for new one from UoE (having previously tested them both yesterday and found them to work fine).

           With first switch connected and PuTTY session opened cannot get RPi to connect to it. See (bodged) screen shots below.

           Tried many permutations of trying to connect using ttyUSB0/1/2 with various permissions set, none yielded any results other than the error messages below.

1500: Swapped 1st UoE power switch out for the second. Plugged it straight in and it works... ???

           Later unplugged it and when reconnected saw the same errors as before. We got rid of these by plugging in the USB cable once the unit was powered on. Does this make any sense, or was it just luck?

           Carried out pulser walkthrough to file R22_0. Use same "best" settings as yesterday.

           Changed polarity of detector bias (from -100V to +100) and observed a similar leakage current as previously (11.5uA) and normal rates/spectra for each detector. No obvious changes from -ve bias polarity. GOOD.

1830: Looked at effect of supplying each FEE64 from various power supplies (as per request PC-S email on Sun 22nd Feb).

           Original configuration :     |  1   2  |  4   3  |  5   7  |  8   6  |    (all in one PSU)

           Changed to:     |  1   -  |  -    -  |  -    -  |  -   -  |       PSU#1

                                    |  3   -  |  -    -  |  -    -  |  -   -  |       PSU#2

                                    |  6   -  |  -    -  |  -    -  |  -   -  |       PSU#3

                                    |  8   -  |  -    -  |  -    -  |  -   -  |       PSU#4

                      with PSUs #3+4 completely unplugged apart from nnaida6+8. In PSUs #1+2, the remainder of the slots were connected as previously (apart from for nnaida3,6,8, in which case they were swapped for another FEE64 at random).

           Initially all PSUs were plugged into one half of the power switch, but the fuse blew. We replaced it with a spare fuse from the unused supply and distributed the PSUs 2 to each half of the switch.

           This configuration yielded larger FWHM than original set up  ---> worsened performance.

 

 

 

  173   Wed Mar 9 12:16:01 2016 TDWednesday 9 March
MSL type BB18(DS)-1000 serial 2998-22
Bias +200V, I_L +=6.505uA, ambient temperature +19.8 deg C
 
DSSSD - AIDA adaptor PCB cabling
 
4 off LH Coupler (Kapton PCB, 5cm), 2x 34-way Samtec ribbon cable (45cm), RH coupler(Kapton PCB, 10cm)
 + 3M 1245 1.4mil copper foil screen ribbon cables + RH coupler only (i.e. not LH coupler)
 + drain wires -> gold-plated Lemo-00 test input connectors 
 
nnaida 11 & 12 AIDA adaptor PCB rev B
nnaida 13 & 14 AIDA adaptor PCB rev C (LK1 fitted) 
ground links LK3 & LK7 fitted to nnaida11-14 AIDA adaptor PCBs

Heavy duty copper cable connects copper front end frames of FEE modules
Nitto 5011N conductive gasket between FEE module and front end frames
 
Standard ASIC settings
 nnaida 11 & 12 - negative input
 nnaida 13 & 14 - positive input
 
Pulser BNC PB-5 
Fall time 1.0ms
Rate 100Hz
Delay 250ns
Ampl 5.00000V
Polarity +
Pulse top Tail
Atten 10x
Clamp ON
- polarity via Cooknell SA1 Summing Amplifier
 
207Bi source, approx centred on DSSSD, approx 3cm from DSSSD

AIDA FEE firmware version 8

File R43
shaping time 8uS
slow comparator 10 (dec)
LEC/MEC fast comparator 24 (dec)
start: 12.05 stop: 15.59
spectra saved to disk 16.59 BST (sic)
Pulser OFF
  291   Tue Jun 7 19:19:34 2016 CG, TD, DK, AEWednesday 8th June

(4 mm Al mask was put upstream of AIDA near 20:20 on 7 June)

 

01.15 Run R1219 started on neutron rich setting.

            Temps ok. Leakage currents ok.

             Plate with holes in front of AIDA , after F11 plastic. F11 plastic count rate ~700cps.

             Keeps getting 'Attempting resychronisation' message in merger terminal window.

             driver 0 10205 consuming almost 100% of CPU. Merger ~20% and data links ~1%

              See attachments 1-4

 

02.15 Run R1220 n-rich setting (BigRIPS run 1218, EURICA off)

          EURICA team retires for the night and cannot get it up and running

          Biases and leak shown as attachments 5-6

          Merger info is shown in attachments 7-9

          CPU Load in attachment 10

          Timestamps against the ADCs and also SYNCS, respectively, attachments 11 and 12

          3:31: Run stopped for the operator to tune the beam

          F11 plastic rate was 700 cps (~heavy ion injection rate)

 

3:43 Run R1221 n-rich setting (BigRIPS 1219, no EURICA)

          4 mm Al mask was removed.

          Pause calls vs. Timestamp is attachment 13

          Merger screenshots are shown as attachments 14-16

          F11 plastic rate is 850 or 900 cps after retune

          ADC v Timestamp is shown as attachment 17.  It can be seen the rate was roughly constant before the operators stopped (corresponding to a long gap of no hits, but now  we go up and down quite a lot in a rather ugly way

          CPU stats (driver to write to HDD in green, merger in red) as attachment 18

          At the time of ~90 in attachment 18, the linkers start to consume all available CPU resources, shown as attachment 19

 

04:35 Run R1222 n-rich setting (BigRIPS 1219 / 1220)

          Ask the operators to reduce the beam intensity by "1/2" -> F11 plastic rate goes from 850 cps to 170 cps, so more like 1/4 effectively

          Merger stats are shown as attachments 20, 21, 22. 

          nnaida1 and nnaida24 seemed to often show pauses (among other ones)

          trying to understand what's going on with the display in Midas, because it has looped around to time zero and is putting new data on to the old data...?

         It seems this condition is much better than before, though

         05:33 stop the run

 

05:38 R R1223 n-rich setting (BigRIPS 1221)

           Ask the operators to resume the previous beam intensity.  (Now like 600 to 800 cps at the F11 plastic)

           attachment 23 shows the beam coming on near time zero.  within <100 seconds, the driver has to fight with many link64 instances and cannot operate correctly

           we understood how to clear the midas histograms so that we can make sense of things.  attachment 24 is ADC, and attachment 25 is pause. 

           you can see some data come smoothly until the system locks down

06.11 R1223 stopped.

 

06.30 Started run R1224.

            Moved Pb bricks downstream of F11 plastic inwards, from a separation of 15cm, to 4cm in an effort to reduce rate in AIDA.

            F11 plastic rate ~900cps.

            No change to vis scalar rates and data still being dropped.

06.45 Stopped run R1224.

            MIDAS plot of ADC vs Timestamp (attachment 26) shows characteristic behaviour.

            Upon writing to disk, for the first minute or so link64 processes consume minimal CPU power. But then very quickly they ramp up consumption and ultimately choke the merger (it seems).

            This is reflected in the ADC v TS plot. Continuous ADC data for first ~1min.

 

06.54 Moved Pb bricks to separation of 2cm. Started run R1225.

            AIDA vis scalar rates reduced slightly, but no change to CPU usage and usual happens - data lost, link64 CPU usage spikes and chokes merger (seemingly).

            F11 plastic rate ~900cps.

07.00 Run R1225 stopped.

           SYNCs stopped being produced. Lost contact with nnaida1.

 

07.25 Pb bricks moved to 1cm apart. Run R1226 started.

            No change to CPU usage (link64 still hogging everything). MIDAS online monitor lost in power cycle so cant view in real-time, but anticipate same outcome.

            Sopped producing SYNCs 07.39. Run 1226 stopped.

 

08.20 Some trouble restarting DAQ and merger.

            As nnaida19 has lost the 'H' for histogramming on the run control page, nnaida21 has now lost the 'X' for data transfer (see attachment 27).

           Removed nnaida21 from merger and normal state of play resumed.

           4mm holey plate + the one attached to it we installed dowstream of F11 plastic.

 

08.50 Run R1227 started.

           CPU usage by link64 ~1% and driver ~70%, much more reasonable. When reloading merger web page, channels flash between bright green and olive. Good.

09.09 Changed to reference mass setting. Run R1227 stopped.

 

09.12 Run R1228 started on reference setting with holey plate still in place.

           R1228 stopped 10.32 (for B2F/F11 entry)

 

  768   Wed Nov 7 01:00:58 2018 CA, CB, TD, OH, PJWWednesday 7 November
10.02 DAQ still running, on file Oct18/R27_9
      Merger and TapeServer ok, no error warnings in terminals

10.07 Good event statistics ok, except nnaida6 rate being high (attachment 1)
      nnaida17 rate ok, but counts very high. May have run fast at some point overnight.
      System wide checks ok, except nnaida7 failure in ADC calibration
      FEE64 temperatures ok (attachment 2)

10.13 Bias/leakage currents slightly higher, but ok (attachment 3)

10:30 1.8.W spectra (attachment 4)

11.10 Stopped the DAQ (R27_9)
      Checked ASIC control - ok
      Started the DAQ again (Oct18/R28_0)
      good event statistics ok, aside from nnaida6 running slightly fast (attachment 5)

15.07 DAQ stop - file Oct18/R28_2

      Detector bias OFF 

      Move AIDA downstream to check position of Clover G7 

16.05 Move back upstream into BRIKEN (CH2)n moderator assembly

      Detector bias ON

16.12 all system wide checks OK *except* nnaida7 fails ADC calibration
      sync all ASIC clocks using ReSYNC
      detector biases & leakage currents OK - see attachments 6 & 7
      FEE64 temperatures OK - see attachment 8
      good event statistics OK *except* nnaida2 - see attachment 9
                                                  see attachment 10 for comparison to statistics 5.1.18

16.41 1.8.W spectra 20us FSR - see attachments 11 & 12

16.55 slow comparator thresholds raised from 10 to 100
      DAQ start (Oct18/R29_0)
      Merger and TapeServer ok - no error warnings in terminals
      good event statistics ok, except nnaida6 running fast (attachment 13)




      
  642   Wed Jun 7 08:02:42 2017 OH, PVWednesday 7 June 16:00 - 24:00
16:02 System wide checks ok
      Good Events statistics (No beam at time!)- attachment 1
      Fee temperatures - attachment 2
      Bias and leakage ok - attachment 3

16:29 BigRIPS starts run 3051
      BRIKEN starts run 49
      AIDA on file R7_80

      Slits brought in to reduce rate to attempt implant-neutron correlation

16:39 DSSD rates from R7_81
 *** DSSSD # 1 count:    182087 old count:    144548 dt:      1.02 s  LEC rate:  36716.57 Hz
 *** DSSSD # 2 count:    295938 old count:    235754 dt:      1.02 s  LEC rate:  58865.45 Hz
 *** DSSSD # 3 count:     80412 old count:     64397 dt:      1.02 s  LEC rate:  15664.13 Hz
 *** DSSSD # 4 count:     94793 old count:     75541 dt:      1.02 s  LEC rate:  18830.22 Hz
 *** DSSSD # 5 count:     23432 old count:     18547 dt:      1.02 s  LEC rate:   4777.98 Hz
 *** DSSSD # 6 count:     66315 old count:     53096 dt:      1.02 s  LEC rate:  12929.39 Hz
 *** DSSSD # 1 count:         0 old count:         0 dt:      1.02 s  HEC rate:      0.00 Hz
 *** DSSSD # 2 count:         8 old count:         4 dt:      1.02 s  HEC rate:      3.91 Hz
 *** DSSSD # 3 count:        23 old count:        20 dt:      1.02 s  HEC rate:      2.93 Hz
 *** DSSSD # 4 count:        38 old count:        32 dt:      1.02 s  HEC rate:      5.87 Hz
 *** DSSSD # 5 count:        13 old count:        10 dt:      1.02 s  HEC rate:      2.93 Hz
 *** DSSSD # 6 count:        11 old count:         8 dt:      1.02 s  HEC rate:      2.93 Hz

17:13 BigRIPS and BRIKEN stop DAQS
      AIDA on file R7_89

17:30 Beam back
      BigRIPS starts run 3052
      BRIKEN starts run 50
      AIDA on file R7_93

17:52 Analysis of R7_93 No timewarps, no MBS timewarps - attachment 4

18:06 System wide checks all ok 
      Bias and leakage ok - attachment 5
      Good events statistics - attachment 6
      FEE temperatures ok - attachment 7

18:27 fRC problem, beam is off
      
18:29 BigRIPS and BRIKEN stop DAQS
      AIDA on file R7_106

18:32 Beam is back
      BigRIPS starts run 3053
      BRIKEN starts run 51
      AIDA on file R7_106

19:33 BigRIPS and BRIKEN stop daqs
      AIDA on file R7_119

19:34 BRIKEN starts run 52
      BigRIPS starts run 3054
      AIDA on file R7_120

20:09 System wide checks ok
      Bias and leakage ok - attachment 8
      Good event statistics - attachment 9
      Fee temperatures - attachment 10

20:28 BigRIPS and BRIKEN stop their DAQs
      AIDA on file R7_131

20:30 BigRIPS starts run 3055
      BRIKEN starts run 53
      AIDA on file R7_131

20:41 Layout 3 - attachment 11
      1.8.L spectrum for each FEE
      Appears to be 4-5 pulser peaks

21:31 BRIKEN and BigRIPS stop their daqs
      AIDA on file R7_144

21:32 BRIKEN starts run 54
      BigRIPS starts run 2056
      AIDA on file R7_144

22:03 System wide checks ok
      Bias and leakage ok - attachment 12
      Good events statistics - attachment 13
      Fee temperatures - attachment 14
      

22:32 Briken and BigRIPS stop their daqs
      AIDA on file R7_156

22:33 BigRIPS starts run 3057
      BRIKEN starts run 55
      AIDA on file R7_156

23:31 BigRIPS and BRIKEN stop their DAQs
      AIDA on file R7_169

23:32 BigRIPS starts run 3058
      BRIKEN starts run 56
      AIDA on file R7_169

23:46 Analysis of R7_168 - attachmemt 15
ELOG V3.1.3-7933898