AIDA GELINA BRIKEN nToF CRIB ISOLDE CIRCE nTOFCapture DESPEC DTAS EDI_PSA 179Ta CARME StellarModelling DCF K40
  AIDA, Page 45 of 46  ELOG logo
ID Date Author Subject
  38   Wed Feb 18 05:49:29 2015 CG, AE, TD, PJC-SWed 18th Feb progress

18/02/15

1300: Error seen when trying to check ASIC settings. See Attachment #1. Power cycle removed error.

           nnaida3 still performing much better than other three cards connected to detector (nnaida1,6,8). Why?

           Noticed nnaida3 was connected to only adapter PCB which did not feature a metal shielding plate on the front?

           Noise in other cards caused by possible short or capacitance between PCB pins and shielding plate?

           -> Removed all shielding plates and no difference seen. Pulser peak widths all still approximately the same.

           nnaida3+6 PCB grounds connected by thin braid, as well as nnaida1+8. These were all removed. No change.

 

1830: Still seeing errors when data is sent through them Merger, see attachments #2-6.

            Attached heavy duty copper braiding in loop, connecting all nnaida PCBs in use. Improved FWHM of nnaida1 by factor of 2. No change in other nnaida.

            Moved kapton and bias from nnaida3 to nnaida11 (same crate, next module along) and saw no appreciable difference in the spectra.

            Changed voltages in PSUs for first 16 nnaida.

           +5V -> +5.5V, -6V -> -6.5V, +7V -> +8V.

           All +5.5V rails at 5.5V, however in PSU#1 (supplying inner FEE modules) -6.5V and +8V rails show variations of +- ~12mV and +- ~4mV respectively, between outlets.

           Installed PSUs with updated voltages.

           nnaida8 FWHM improved by factor of 2 but no difference in other nnaida.

          Current configuration nnaida1,6,8,11. nnaida1+8 connected to p+n side, nnaida6+11 connected to n+n side.

          Current FWHM: nnaida1 ~500ch, nnaida6 ~1500ch, nnaida8 ~600ch, nnaida11 ~120ch.

 Update response from Patrick:-

Please see posting number 39 for ideas to improve noise and possible reasons why some FEE64 are quieter than others.

I think the SYNC problem is likely due to the version of VHDL perhaps not including the flush of buffers and with the widely different data rates. 224k against 3k. 

This should improve with the VHDL update as I think the flush system is more efficient.

 

 

Attachment 1: nnaida1_load_failure.png
nnaida1_load_failure.png
Attachment 2: merge_conole_error_mesages.png
merge_conole_error_mesages.png
Attachment 3: nnaida1_stats.png
nnaida1_stats.png
Attachment 4: nnaida3_stats.png
nnaida3_stats.png
Attachment 5: nnaida6_stats.png
nnaida6_stats.png
Attachment 6: nnaida8_stats.png
nnaida8_stats.png
Attachment 7: nnaida1_hits.png
nnaida1_hits.png
Attachment 8: nnaida1_spec.png
nnaida1_spec.png
Attachment 9: nnaida6_hit.png
nnaida6_hit.png
Attachment 10: nnaida6_spec.png
nnaida6_spec.png
Attachment 11: nnaida8_hit.png
nnaida8_hit.png
Attachment 12: nnaida8_spec.png
nnaida8_spec.png
Attachment 13: nnaida11_hit.png
nnaida11_hit.png
Attachment 14: nnaida11_spec.png
nnaida11_spec.png
Attachment 15: goodEvents.png
goodEvents.png
  37   Tue Feb 17 08:03:32 2015 Patrick Coleman-Smith[How To] Set up the Raspberry Pi for PuTTY

Quote:

When logged in and before opening PuTTY open a cmdtool window.

cd /dev

sudo chmod 777 /dev/ttyUSB0

then you should be able to run PuTTY.

This is based on notes in my log-book.

 

 

Tried this when we got in this morning and successfully changed the permissions for /dev/ttyUSB0, but made no difference to the error received when opening the PuTTY session, which was:

            PuTTy Fatal Error

            Unable to open connection to:

            Unable to open serial port.

  36   Tue Feb 17 06:32:24 2015 CG, AE, TDTues 17th Feb progress

17/02/15

1515: Installed detector BB18 2977-7 with 3 modified kapton cables, one unmodified (in nnaida1) with 207Bi source.

           Bias voltage @ -100V with leakage current -11.6uA @ ambient temp of ~20oC.

           nnaida1,3,6,8 connected to detector, all with shaping time of 2us and hold time 8us.

           Slow comparator thresholds around 0x18 and fast comparators 0xf (see below images).

           Pulser at 50,000 with x5 attenuator @ 25Hz. Both polarities supplied via use of Ortec 433A dual sum and invert amp.

           nnaida1+6 p+n side, -ve bias. nnaida3+8 n+n side, ground.

          

           nnaida3 most well behaved, with low rate similar to that of pulser rate and no missing channels. Waveforms look good.

           Pulser peak has smallest FWHM @ ~150ch, compared to 1000s of ch for the other nnaida.

           For comparison, nnaida7 (not connected to detector) has peak width of ~18ch FWHM.

           nnaida1,6,8 have typical pulser peak widths of the order 1000-3000ch FWHM. Peak too broad in nnaida6 to be distinguishable from noise peak.

 

           Waveforms from nnaida3 stable and as expected. nnaida1+6 slightly more variable and noisy.

           Waveforms from nnaida8 see much greater noise and variability, including rail-to-rail transitions.

           Increasing the pre-amp reference from 0x30 to 0x60, removes rail-to-rail transitions, but waveforms remain just as noisy.

 

1650: Successfully started Merge and Tape servers, writing data to disk.

            Merge terminal window shows errors regarding Sync pulse timestamp sequence errors (see attachment #18). 

 

1900: Installed Caen N1419 floating HV bias supply.

            Connected to detector via nnaida3, positively biasing n-side through core with p-side as low V reference through braid. Saw no leakage current => open circuit.

            After some problem solving found reversing the bias and negatively biasing p-side worked. Possible broken bond wires delivering bias on n-side.

            Connected to nnaida8 (also positive bias to n-side) and found short circuit. Saw leakage current of 200uA (trip level) @ 5V.

            Changed to negative polarity bias and connected to nnaida6 and saw sensible leakage current of -11.5uA @ -100V bias.

            Spectra for each module showed FWHM for the pulser peaks to be: nnaida1 ~800ch, nnaida3 ~150ch, nnaida6 ~3000ch, nnaida8 ~1200ch.

            FWHM in nnaida1 reduced by ~1/3, nnaida6 shows little change, nnaida8 reduced by ~1/2. nnaida3 shows no change, but in line with what was seen at DL. (w.r.t peak widths seen last night using Selena bias supply)

            nnaida3 performing much better than other three cards connected to detector, but in line with what was seen at DL. Other 3 cards very noisy.

 

Attachment 1: 10.png
10.png
Attachment 2: 15.png
15.png
Attachment 3: 19.png
19.png
Attachment 4: 21.png
21.png
Attachment 5: 11.png
11.png
Attachment 6: 12.png
12.png
Attachment 7: 13.png
13.png
Attachment 8: 14.png
14.png
Attachment 9: 16.png
16.png
Attachment 10: 17.png
17.png
Attachment 11: 18.png
18.png
Attachment 12: 25w.png
25w.png
Attachment 13: 26w.png
26w.png
Attachment 14: 27w.png
27w.png
Attachment 15: 28w.png
28w.png
Attachment 16: 30.png
30.png
Attachment 17: 31.png
31.png
Attachment 18: merge.png
merge.png
Attachment 19: merge_tape_etc.png
merge_tape_etc.png
Attachment 20: 3_floatingHV.png
3_floatingHV.png
Attachment 21: 6_floatingHV.png
6_floatingHV.png
Attachment 22: 8_floatingHV.png
8_floatingHV.png
  35   Mon Feb 16 12:17:21 2015 Patrick Coleman-SmithMACB update for 50Mhz external clock

 This version of the MACB has an additional selection at 5 for a ROOT module.

This will operate the Correlation Scalar signals used for RIBF and use the External Clock signal directly for the FEE64 50MHz distribution.

This has been tested at Daresbury with and external clock source and operates successfully with the merger.

 

Attachment 1: macb_top_revB_16Feb15.jed
  34   Mon Feb 16 09:41:45 2015 Patrick Coleman-Smith[How To] Set up the Raspberry Pi for PuTTY

When logged in and before opening PuTTY open a cmdtool window.

cd /dev

sudo chmod 777 /dev/ttyUSB0

then you should be able to run PuTTY.

This is based on notes in my log-book.

 

  33   Mon Feb 16 06:17:31 2015 TD, AEV & CGMonday 16th Feb progress

16/02/2015

1500: AIDA moved into operational position.

           Water cooling circuit visually checked, fittings, etc for loose fittings/snags/kinks. No problems

           Julabo FL11006 chiller moved into position with mains transformer, filled and turned on without problem (small leak from rear overflow, due to overfilling).

           Took roughly 2 ~30L water containers to fill reservoir.

           Brief leak at connection between back of chiller and yellow hose, bolt tightened and it stopped.

           Having been turned on and loop filled, reservoir at ~50% full. Pressure ~10 psi.

           No leaks observed in main coolant loop.

           When standing downstream of AIDA RH flow gauge blurred due to high rotational speed, LH flow gauge rotating at ~1 rev/s.

           Two FEE modules closest to centre in each block checked for power cabling, TS distribution and network cables. All ok.

            MACBs front panel cabling checked, no obvious problems. TS distribution tree in order.

           Power on for NIM bins and fan tray, network switches and Raspberry Pi. Not yet for the FEE module PSUs.

 

           1 corner of each new USB power supply damaged in transit.

           Fuses changed from 10A -> 16A in each PSU. Old 10A fuses taped to back of each module.

 

1730: Turned on nnaida1-16. Temperatures stable. All on firmware version 0xa4ed006.

            Input pulser into all FEE cards. All FEEs bar nnaida5 well-behaving. nnaida12 has several missing channels.

            Typical pulser peak width for -ve input modules was ~14ch FWHM with shaping time of 1us.

            Typical pulser peak width for +ve input modules was ~27ch FWHM with shaping time of 1us.

            Changing shaping time of nnaida10 from 1->2.5us reduced FWHM from 27ch to 23ch.

          

Attachment 1: temperatures & FEE firmware revisions nnaida1-16

 

 

Attachment 1: 1.png
1.png
Attachment 2: nnaida4_sample.png
nnaida4_sample.png
Attachment 3: nnaida16_sample.png
nnaida16_sample.png
Attachment 4: nnaida5_stats.png
nnaida5_stats.png
Attachment 5: nnaida13_sample.png
nnaida13_sample.png
Attachment 6: nnaida4_params.png
nnaida4_params.png
Attachment 7: nnaida13_params.png
nnaida13_params.png
Attachment 8: 2015-02-16_14.52.39.jpg
2015-02-16_14.52.39.jpg
Attachment 9: 2015-02-16_14.53.50.jpg
2015-02-16_14.53.50.jpg
Attachment 10: 2015-02-16_14.54.48.jpg
2015-02-16_14.54.48.jpg
  32   Sun Feb 15 22:30:48 2015 TDJulabo FL11006 Operating Manual
Attachment 1: Julabo_FL11006.pdf
Julabo_FL11006.pdf Julabo_FL11006.pdf Julabo_FL11006.pdf Julabo_FL11006.pdf Julabo_FL11006.pdf Julabo_FL11006.pdf Julabo_FL11006.pdf Julabo_FL11006.pdf
  31   Sun Feb 15 06:12:00 2015 TD, AEV & CGHow to mount USB disk with NTFS
Mount external USB expansion disk with NTFS filesystems 
with the (superuser) command:

su root
password:

mount -t ntfs-3g /dev/sdd1 /ntfs

[root@aidas1 /]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_aidas1-lv_root
                       50G   33G   15G  69% /
tmpfs                 3.9G  4.3M  3.9G   1% /dev/shm
/dev/sda1             485M   61M  399M  14% /boot
/dev/mapper/vg_aidas1-lv_home
                      860G  201M  816G   1% /home
/dev/mapper/Data1-data10
                      1.8T  1.4T  309G  83% /data10
/dev/sdd1             3.7T  1.3T  2.4T  36% /ntfs
  30   Tue Feb 10 16:01:50 2015 Chris Griffin, Alfredo EstradeHigh data rate - Pause/Resume

06/02/15

 A look at the data rate at which Pause/Resumes start to cause missing data.

Pulser settings:

  • 100 Hz
  • 0.5V amplitude

Slow comparitor thresholds were altered using the ASIC4 page to artificially increase the data rate in the ASICs.

Default settings for all modules, apart from the changing slow comp threshold.

nnaida13+14 both functioning well. nnaida11+12 both have one noisy channel contributing to high data rate.

 

Echoing Alfredo's previous post, using the AIDA Good Events and AIDA Data Rate from the stats page as metrics, I found there to be no Pause/Resume items present in the data up to a Good Events rate of ~250-300 kHz and Data Rate of ~1-1.2 MHz.

Around this point the data shifts very quickly from containing no Pause/Resume items to having a rate of ~18 Hz, almost as a step function. At this point the Good Events and AIDA data rate sharply reach a maximum rate of 300 kHz and 1.2 MHz respectively. The rate of AIDA SYNC data items drops sharply at this point and decreases slowly with decreasing threshold.

Included are some plots showing this for each of the modules and some summary plots.

Further to the data rate at which the appearance of Pause/Resume items causes significant data loss, I looked at what happens when you break this threshold and then come back down, i.e. do the Pause/Resume items persist?

In short, no. Starting from a threshold of 64 and working down to 1, then taking the slow comparitor threshold back to a level at which no Pause/Resumes were present, the Good Events, AIDA SYNC and AIDA Data rates all went back to their original values within a couple of refreshes of the stats screen (and stayed as such thereafter).

Attachment 1: GoodEvts_v_thresh.png
GoodEvts_v_thresh.png
Attachment 2: AIDAdata_v_thresh.png
AIDAdata_v_thresh.png
Attachment 3: AIDAsync_v_thresh.png
AIDAsync_v_thresh.png
Attachment 4: PauseResume_v_thresh.png
PauseResume_v_thresh.png
Attachment 5: ResumeRate_v_AIDAdata.png
ResumeRate_v_AIDAdata.png
Attachment 6: ResumeRate_v_GoodEvts.png
ResumeRate_v_GoodEvts.png
  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.

Attachment 1: Integrating_AIDA_with_other_Acquisition_Systems.pdf
Integrating_AIDA_with_other_Acquisition_Systems.pdf Integrating_AIDA_with_other_Acquisition_Systems.pdf Integrating_AIDA_with_other_Acquisition_Systems.pdf
  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).
Attachment 1: R61part_ts_dist_adc_hit.png
R61part_ts_dist_adc_hit.png
Attachment 2: R61part_rates.png
R61part_rates.png
Attachment 3: R61part_t1_hits_ts_adc.png
R61part_t1_hits_ts_adc.png
Attachment 4: R61part_t1_hits_ts_adc_zoom.png
R61part_t1_hits_ts_adc_zoom.png
Attachment 5: R61part_t1_hits_ts_info.png
R61part_t1_hits_ts_info.png
Attachment 6: R61part_ts_info_fee.png
R61part_ts_info_fee.png
Attachment 7: loopAIDAsort.cpp
/*********/
//#include <bitset>
#include <fstream>
#include <iostream>
#include <stdio.h>
#include <sstream>
#include <string>
#include <ctime>

#include <TFile.h>
#include <TTree.h>
#include <TH1I.h>
#include <TH2I.h>
#include <TGraph.h>
#include <TCanvas.h>

//#include "Common.h"


//using namespace std;
/*********/


//ts_0 in usec
void LoopTree(string inFile, int downscale=1, long long n_last= -1, int ts_0=-1, bool b_print=false, bool b_quit_ts=false){



  struct struct_entry_sort{
    long long tm_stp; //reconstructed timestamp (MSB+LSB)
    long long info; //MBS info data (external timestamp), anything else(?)
    int mod_id;
    int ch_id;
    int type; // QQQ: 0= 20 MeV or 1 GeV (decays), 1= 20 GeV (checked pulser data only in type 0)
              // type>=10: type = info_code+10 (i.e., PAUSE, RESUME, SYNC100, etc...)
    int adc_data;
    bool sync_flag; // check SYNC100 pulses received for this module
    bool pause_flag; // check Pause signals followed by proper Resume signal: true= SYNC100 paused...
  };



  //***** histograms! many...
  //

  //delta ts: any->any [100]
  //          adc->adc [100]
  //          adc(feei)->adc(feej) [1]
  //          adc(sidei)->adc(sidej) [1]
  //          !adc->!adc [1]
  //1,2,3,5,10,15,20,50,100
  TH1D *Hdts_any[10];
  Hdts_any[0]= new TH1D("Hdts_any0","#Delta ts_{(i+1,i)} !ANY DATA;ts_{i+1} - ts_{i} [usec]",4400,-20,200); //200 us full scale
  Hdts_any[1]= new TH1D("Hdts_any1","#Delta ts_{(i+2,i)} !ANY DATA;ts_{i+2} - ts_{i} [usec]",4400,-20,200); //200 us full scale
  Hdts_any[2]= new TH1D("Hdts_any2","#Delta ts_{(i+3,i)} !ANY DATA;ts_{i+3} - ts_{i} [usec]",4400,-20,200); //200 us full scale
  Hdts_any[3]= new TH1D("Hdts_any3","#Delta ts_{(i+5,i)} !ANY DATA;ts_{i+5} - ts_{i} [usec]",4400,-20,200); //200 us full scale
  Hdts_any[4]= new TH1D("Hdts_any4","#Delta ts_{(i+10,i)} !ANY DATA;ts_{i+10} - ts_{i} [usec]",4400,-20,200); //200 us full scale
  Hdts_any[5]= new TH1D("Hdts_any5","#Delta ts_{(i+15,i)} !ANY DATA;ts_{i+15} - ts_{i} [usec]",4400,-20,200); //200 us full scale
  Hdts_any[6]= new TH1D("Hdts_any6","#Delta ts_{(i+20,i)} !ANY DATA;ts_{i+20} - ts_{i} [usec]",4400,-20,200); //200 us full scale
  Hdts_any[7]= new TH1D("Hdts_any7","#Delta ts_{(i+50,i)} !ANY DATA;ts_{i+50} - ts_{i} [usec]",4400,-20,200); //200 us full scale
  Hdts_any[8]= new TH1D("Hdts_any8","#Delta ts_{(i+100,i)} !ANY DATA;ts_{i+100} - ts_{i} [usec]",4400,-20,200); //200 us full scale

  TH1D *Hdts_adc[10];
  Hdts_adc[0]= new TH1D("Hdts_adc0","#Delta ts_{(i+1,i)} !ADC(low) DATA;ts_{i+1} - ts_{i} [usec]",4400,-20,200); //200 us full scale
  Hdts_adc[1]= new TH1D("Hdts_adc1","#Delta ts_{(i+2,i)} !ADC(low) DATA;ts_{i+2} - ts_{i} [usec]",4400,-20,200); //200 us full scale
  Hdts_adc[2]= new TH1D("Hdts_adc2","#Delta ts_{(i+3,i)} !ADC(low) DATA;ts_{i+3} - ts_{i} [usec]",4400,-20,200); //200 us full scale
  Hdts_adc[3]= new TH1D("Hdts_adc3","#Delta ts_{(i+5,i)} !ADC(low) DATA;ts_{i+5} - ts_{i} [usec]",4400,-20,200); //200 us full scale
  Hdts_adc[4]= new TH1D("Hdts_adc4","#Delta ts_{(i+10,i)} !ADC(low) DATA;ts_{i+10} - ts_{i} [usec]",4400,-20,200); //200 us full scale
  Hdts_adc[5]= new TH1D("Hdts_adc5","#Delta ts_{(i+15,i)} !ADC(low) DATA;ts_{i+15} - ts_{i} [usec]",4400,-20,200); //200 us full scale
  Hdts_adc[6]= new TH1D("Hdts_adc6","#Delta ts_{(i+20,i)} !ADC(low) DATA;ts_{i+20} - ts_{i} [usec]",4400,-20,200); //200 us full scale
  Hdts_adc[7]= new TH1D("Hdts_adc7","#Delta ts_{(i+50,i)} !ADC(low) DATA;ts_{i+50} - ts_{i} [usec]",4400,-20,200); //200 us full scale
  Hdts_adc[8]= new TH1D("Hdts_adc8","#Delta ts_{(i+100,i)} !ADC(low) DATA;ts_{i+100} - ts_{i} [usec]",4400,-20,200); //200 us full scale

  TH1D *Hdts_fee[1];
  Hdts_fee[0]= new TH1D("Hdts_fee0","#Delta ts_{(i+1,i)} !ADC(low), diff. FEE;ts_{i+1} - ts_{i} [usec]",4400,-20,200); //200 us full scale

  TH1D *Hdts_side[2];
  Hdts_side[0]= new TH1D("Hdts_side0","#Delta ts_{(i+1,i)} !ADC(low), side0->1;ts_{i+1} - ts_{i} [usec]",4400,-20,200); //200 us full scale
  Hdts_side[1]= new TH1D("Hdts_side1","#Delta ts_{(i+1,i)} !ADC(low), side1->0;ts_{i+1} - ts_{i} [usec]",4400,-20,200); //200 us full scale

  TH1D *Hdts_info[1];
  Hdts_info[0]= new TH1D("Hdts_info0","#Delta ts_{(i+1,i)} !info DATA;ts_{i+1} - ts_{i} [usec]",4400,-20,200); //200 us full scale
 
  TH1D *Hdts_ooo[1];
  Hdts_ooo[0]= new TH1D("Hdts_ooo0","#Delta ts_{(i+1,i)} !out-of-order!;ts_{i+1} - ts_{i} [usec]",15000,-3e6,0); //500 us full scale
 

  TH1D * Hts[2];
  Hts[0]= new TH1D("Hts0","Time-stamp;ts [usec]",2000,0,27e5);
  Hts[1]= new TH1D("Hts1","Time-stamp;ts [usec]",2000,91e9,97e9);



  //Rate hitograms
  TH1D * HrateFEE_ts[4];
  TH1D * HrateFEE_ch[4];
  TH1D * HrateADChigh_ts[1];
  TH1D * HrateInfo_ts[1];
  
  TH1I * HhitsADC[5];
  TH1I * HhitsInfo[4];
    
  TH2I * HtsFEE[3];
  TH2I * HtsInfo[1];
  TH2D * HtsCh[4];


  TH2I * HInfoFEE[4];

  double max_bin;
  if(n_last>0) max_bin= n_last;
  else max_bin= 1.e7;
  TH2I * HtsEvent[2];
  //HtsEvent[0]= new TH2I("HtsEvent0","Time-stamp vs entry;entry #;ts [usec]",200,0,max_bin,1000,0,27e5);
  HtsEvent[1]= new TH2I("HtsEvent1","Time-stamp vs entry;entry #;ts [usec]",500,0,max_bin,500,92e9,97e9);
  //sEvent[1]= new TH2I("HtsEvent1","Time-stamp vs entry;entry #;ts [usec]",500,0,max_bin,500,92.4e9,92.44e9);



  // variables for distribution of time-stamp differences
  double dts;
  double ts100_any[101];
  double ts100_adc[101];
  //  long long tsinide01;
  //  long long ts_side10;
  // long long ts_fee; 
  double ts_info= -1;
  int index_adc=0;
  int index_any=0;
  int index_prev;
  int last_side, this_side;
  int last_fee, this_fee;

  int step_back[9]={1,2,3,5,10,15,20,50,100};
  int steps;

  double ts;

  for(int i=0;i<101;i++){
    ts100_any[i]= -1;
    ts100_adc[i]= -1;
  }


  int Nooo=0;

  int info_code_prev, mod_id_prev, type_prev;


  //logfile
  ofstream logfile("outputLoop_R61_5.txt");

  time_t t_start; //, t_stop;

  TFile* input_file; 
  input_file = new TFile(inFile.data(),"read");
 
  if (input_file != 0){
    input_file->ls();

    TTree * input_tree;
    input_tree= (TTree*) input_file->Get("AIDA_sort");

    if(input_tree !=0) input_tree->Print();
    else {
      cout << "\n WARNING@ could not assign AIDA_sort Tree...." << endl;
      exit(0);
    }


    //tree from Converter step will data in a struct_entry_midas structure
    struct_entry_sort entry_1;

    input_tree->SetMakeClass(1);
    input_tree->SetBranchAddress("entry_sort",&entry_1,0);
    input_tree->SetBranchStatus("entry_sort",1);

    //number of data points in TTree
    long long n_entries;
    n_entries = input_tree->GetEntries();

    cout << "\nNumber of entries in input tree= " << n_entries << ", in file " << inFile << endl;
    logfile << "\nNumber of entries in input tree= " << n_entries << ", in file " << inFile << endl;
  


    //get run time... properly...
    long long time_first, time_last;

    time_first= 0;
    for(long long i=0; i<=100000; i++){
      input_tree->GetEntry(i);
      if(entry_1.sync_flag){
	time_first= entry_1.tm_stp;
	i=100000+1;
      }
    }
    if(time_first<=0){
      cout << "\n\n**** WARNING: Couldn't find Synchronized data in first 100K entries of file! ****\n" << endl;
      time_first=0;
    }
    input_tree->GetEntry(n_entries-1);
    time_last= entry_1.tm_stp;

    cout << "\n----------------------------------------------------------------------------"
    	 << "\n  Inititial time stamp= " <<time_first;
    cout << "\n  Lenght of run= "<<time_last-time_first <<" tm-stp= "<<(time_last-time_first)/1.e8 <<" sec"<<endl;




    //Define histograms that need to know run lenght....
    double ts_low, ts_up; //in usc
    double ts_sec;
    //    int ts_0;
    //in msec units!
    if(ts_0<0) ts_0 = time_first/100000; // 10x ns -> ms
    
    cout << " .... using ts_0= " << ts_0;

    //and this in usec units!
    ts_low= ts_0*1000.;
    ts_up= ts_low+20.e6;

    cout << "msec, ts_low= " << ts_low << " usec, ts_up= " << ts_up << " usec" << endl<<endl;

    int fee_index;
    bool b_ts_window;

    //Rate histograms

    int ts_0_sec= int(1.*time_first/1e8);
    //2 hrs, 10sec/bin
    HrateFEE_ts[0]= new TH1D("HrateFEE_ts0","Rate - ADClow(nnaida11);time-stamp [s];rate [1/s]",360,ts_0_sec,ts_0_sec+3600);
    HrateFEE_ts[1]= new TH1D("HrateFEE_ts1","Rate - ADClow(nnaida12);time-stamp [s];rate [1/s]",360,ts_0_sec,ts_0_sec+3600);
    HrateFEE_ts[2]= new TH1D("HrateFEE_ts2","Rate - ADClow(nnaida13);time-stamp [s];rate [1/s]",360,ts_0_sec,ts_0_sec+3600);
    HrateFEE_ts[3]= new TH1D("HrateFEE_ts3","Rate - ADClow(nnaida14);time-stamp [s];rate [1/s]",360,ts_0_sec,ts_0_sec+3600);

    HrateFEE_ch[0]= new TH1D("HrateFEE_ch0","Rate - ADClow(nnaida11);ch; rate [1/s];time-stamp [s]",64,0,64);
    HrateFEE_ch[1]= new TH1D("HrateFEE_ch1","Rate - ADClow(nnaida12);ch; rate [1/s];time-stamp [s]",64,0,64);
    HrateFEE_ch[2]= new TH1D("HrateFEE_ch2","Rate - ADClow(nnaida13);ch; rate [1/s];time-stamp [s]",64,0,64);
    HrateFEE_ch[3]= new TH1D("HrateFEE_ch3","Rate - ADClow(nnaida14);ch; rate [1/s];time-stamp [s]",64,0,64);

    HrateADChigh_ts[0]= new TH1D("HrateADChigh_ts0","Rate - ADChigh(any FEE);time-stamp [s];rate [1/s]",360,ts_0_sec,ts_0_sec+3600);
    HrateInfo_ts[0]= new TH1D("HrateInfo_ts0","Rate - Info Types;time-stamp [s];rate [1/s]",360,ts_0_sec,ts_0_sec+3600);

    //Info types for different FEEs (sum and vs time)
    HInfoFEE[0]= new TH2I("HInfoFEE0","Info Code vs FEE;Info Type;nnaida",16,0,16,4,11,15);
    HInfoFEE[1]= new TH2I("HInfoFEE1","Time-stamp vs FEE(Pause/Resume);time-stamp [s];nnaida",240,ts_0_sec,ts_0_sec+3600,4,11,15);
    HInfoFEE[2]= new TH2I("HInfoFEE2","Time-stamp vs FEE(SYNC100);time-stamp [s];nnaida",240,ts_0_sec,ts_0_sec+3600,4,11,15);
    HInfoFEE[3]= new TH2I("HInfoFEE3","Time-stamp vs FEE(Disc.);time-stamp [s];nnaida",240,ts_0_sec,ts_0_sec+3600,4,11,15);


    //hist vs time
    
    HhitsADC[0]= new TH1I("HhitsADC0","Rate [1/ms] - ADClow(nnaida11);time-stamp [ms]",20000,ts_0,ts_0+20000);
    HhitsADC[1]= new TH1I("HhitsADC1","Rate [1/ms] - ADClow(nnaida12);time-stamp [ms]",20000,ts_0,ts_0+20000);
    HhitsADC[2]= new TH1I("HhitsADC2","Rate [1/ms] - ADClow(nnaida13);time-stamp [ms]",20000,ts_0,ts_0+20000);
    HhitsADC[3]= new TH1I("HhitsADC3","Rate [1/ms] - ADClow(nnaida14);time-stamp [ms]",20000,ts_0,ts_0+20000);
    HhitsADC[4]= new TH1I("HhitsADC4","Rate [1/ms] - ADChigh;time-stamp [ms]",20000,ts_0,ts_0+20000);
    
    HhitsInfo[0]= new TH1I("HhitsInfo0","Rate [1/ms] - PAUSE/RESUME;time-stamp [ms]",20000,ts_0,ts_0+20000);
    HhitsInfo[1]= new TH1I("HhitsInfo1","Rate [1/ms] - RESUME TS;time-stamp [ms]",20000,ts_0,ts_0+20000);
    HhitsInfo[2]= new TH1I("HhitsInfo2","Rate [1/ms] - SYNC100;time-stamp [ms]",20000,ts_0,ts_0+20000);
    HhitsInfo[3]= new TH1I("HhitsInfo3","Rate [1/ms] - Discr. Data;time-stamp [ms]",20000,ts_0,ts_0+20000);


    HtsFEE[0]= new TH2I("HtsFEE0","Time-stamp vs FEE(ADClow);ts [ms];nnaida",1000,ts_0,ts_0+20000,4,11,15);
    HtsFEE[1]= new TH2I("HtsFEE1","Time-stamp vs FEE(SYNC100);ts [ms];nnaida",1000,ts_0,ts_0+20000,4,11,15);
    HtsFEE[2]= new TH2I("HtsFEE2","Time-stamp vs FEE(Pause/Res.);ts [ms];nnaida",1000,ts_0,ts_0+20000,8,11,15);

    //  HtsFEE[0]= new TH2I("HtsFEE0","Time-stamp vs FEE\# (ADClow);ts [msec];nnaida\# ",2000,ts_0,ts_0+20000,4,10.5,14.5);
    
    HtsInfo[0]= new TH2I("HtsInfo0","Time-stamp vs InfoCode;ts [ms];Info Type",1000,ts_0,ts_0+20000,16,0,16);
    
 
    HtsCh[0]= new TH2D("HtsCh0","Time-stamp vs Ch. (nnaida11);ts [ms];ch",5000,ts_0,ts_0+5000,64,0,64);
    HtsCh[1]= new TH2D("HtsCh1","Time-stamp vs Ch. (nnaida12);ts [ms];ch",5000,ts_0,ts_0+5000,64,0,64);
    HtsCh[2]= new TH2D("HtsCh2","Time-stamp vs Ch. (nnaida13);ts [ms];ch",5000,ts_0,ts_0+5000,64,0,64);
    HtsCh[3]= new TH2D("HtsCh3","Time-stamp vs Ch. (nnaida14);ts [ms];ch",5000,ts_0,ts_0+5000,64,0,64);




    t_start= time(0); //lets count how long it takes to loop through tree

    
    //now looping only over first 99 events, or up to n_entries, whatever is less
    if(n_last<1 || n_last>n_entries) n_last= n_entries;
   
    //  input_tree->GetEntry(0);

    for(long long i=0; i<n_last; i=i+downscale){
      //
      //  do stuff...
      //

      //    entry_0.tm_stp= entry_1.tm_stp;
      //    entry_0.type= entry_1.type;
      //    entry_0.info= entry_1.info;
... 343 more lines ...
  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
  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.

Attachment 1: Power_Supply_setup_and_options_for_RIKEN_February_2015.pdf
Power_Supply_setup_and_options_for_RIKEN_February_2015.pdf Power_Supply_setup_and_options_for_RIKEN_February_2015.pdf Power_Supply_setup_and_options_for_RIKEN_February_2015.pdf
  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.
 
  24   Wed Jan 28 16:12:52 2015 Tom DavinsonAIDA Tests at STFC DL - 27-28.1.15 - TD & PCS
MSL type BB18-1000 2998-22 bias +200V I_L +3.52uA


Detector bias CAEN N1419 Programmable HV Power Supply
  - FAGND isolated from AGND (AGND = NIM chassis ground)
  - floating HV supply, <5mV pp noise specification
  - configured + polarity, i.e. core to nnaida11 & nnaida12 MSL type BB18 n+n ohmic strips
                                braid to nnaida12 & nnaida13 MSL type BB18 p+n junction strips
  - configured bias voltage to 200V, max bias voltage 200V, max leakage current 20uA,
    trip 10s, ramp up/down 1V/s


BNC PB-5

amp 0.5V
atten x1
tau_d 1ms
freq 100Hz
pol - (output split via EG&G Ortec 433A to generate + polarity too)


PSU

Standard AIDA FEE64 PSU + new filter PCBs


Adaptor

nnaida11 & nnaida12 - polarity input (n+n ohmic strips)
  MSL type BB18 adaptor PCB rev 180713 LK 3 & 7
nnaida13 & nnaida14 + polarity input (p+n junction strips)
  MSL type BB18 adaptor PCB rev 290114 LK 1, 3, 5 & 7

+/- test inputs terminated by 50 Ohm

DSSSD grounded locally at nnaida12 & nnaida13 adaptor PCBs
by ground links LK 1 & 5

Adaptor PCB grounds connected by thick copper braid (see attached images)

FEE64

nnaida11 2b:09:ce
nnaida12 2b:09:e8
nnaida13 2b:09:07
nnaida14 2b:22:55

FEE firmware release 0x16cee018


ASIC parameters

  Default ASIC parameters (EXPERIMENT/AIDA/2014Aug13-13.44.58) except
  - shaping time 2us
  - slow comparator 64 (hex 40)
  - nnaida11 & nnaida12 preAmp reference 0x30 -> 0x38
    which will reduce linear output range but significantly stabilises
    negative polarity input ASICs


Typical pulser peak widths for nnaida11, 12, 13 and 14 c. 130-150ch FWHM.
Without the copper braid connecting the two adaptor PCBs the peak widths
are typically 200-250ch FWHM.



The problem observed last week (leakage current > 20uA, bias c. 3V, i.e. an
apparent 150k short) was found to be due to a fault on the n+n side FEE Adaptor
PCB rev 290114. Specifically the left hand connector was faulty. The exact
nature of the fault has not yet been determined but will be investigated.

For time being the rev 290114 PCB has been replaced by a rev 180713 PCB
with a 2-way IDC connector from the HV cable (core) to LK1.
Attachment 1: IMG_0881.JPG
IMG_0881.JPG
Attachment 2: IMG_0882.JPG
IMG_0882.JPG
Attachment 3: IMG_0883.JPG
IMG_0883.JPG
  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.
Attachment 1: ASIC_settings_Jan20_2015.png
ASIC_settings_Jan20_2015.png
Attachment 2: R49few_a_bckgrnd_multiplicity.png
R49few_a_bckgrnd_multiplicity.png
Attachment 3: R49few_a_bckgrnd_xy.png
R49few_a_bckgrnd_xy.png
Attachment 4: R49few_a_bckgrnd_dt_event.png
R49few_a_bckgrnd_dt_event.png
Attachment 5: R49few_a_bckgrnd_EfEb.png
R49few_a_bckgrnd_EfEb.png
  22   Thu Jan 22 13:50:33 2015 Alfredo and TomFurther measurements with filtered PSU
Jan 20, 2015

Test settings: DSSD biased at 100V, with 3.5 uA leakage current. Pulser at 0.5 V, split and inverted for both
positive and negative polarity. Frequency at 100 Hz.


++SHAPING TIME++

We varied shaping time (Tsh), and adjusted hold time (Th) accordingly. We measured the width of pulser spectra
for two channels using 'integrate' function of spectrum browser.

 Tsh	 Th	nnaida#11-2.6L	nnaida#13-2.6L
[usec]	[usec]	 FWHM [ch]	 FWHM [ch]
0.5	2	146		109
1	2	133		113
2	2	131		116
4	6	130		126
8	8	145		136

note: Tsh= ( 0.5*offset9 + 0.5) usec, Th= 2*offset7 usec

The first two data points where saved to file R44_0.gz, and R45_0.gz. Starting from the Tsh=2usec measurement,
NNAIDA#12 was causing communication issues with the merger/tape server, so we don't have files for last few.

Due to limited storange in AIDA PC, data was stored to external drive provided by Vic
(/media/data/TapeData/Test100/), and backued up temporarly also in Edinburhg
(/Disk/ds-sopa-personal/aestrade/data/AIDA/).


++THRESHOLDS++

Next step was to adjust threshold of the slow comparator, in order to lower them and take data looking for
background alpha radioactivity. 

At this point NNAIDA#13 had stopped producing data (probably similar issue as NNAIDA#12, which could be
recovered with power cycling FEEs), so we used nnaida#14

FEE		Eth	rate/channel	integral(pulse peak):integral(noise peak)
nnaida#11	0x40	115 Hz (~only pulser)
nnaida#14	0x40	115 Hz(~only pulser)

nnaida#14	0x20	~350 Hz			2:1

nnaida#11	0x10	~150 Hz			1:2	(one channel very noisy @ 15kHz)
nnaida#14	0x10	~5 kHz (asic 1-3)	80:1
		0x10	~3kHz-100 Hz (asic 4)


For background run (see next elog entry) threshold values set at:
 nnaida#11= 0x16
 nnaida#12= 0x40 
 nnaida#13= 0x20
 nnaida#14= 0x16
  21   Wed Jan 14 15:29:01 2015 PatrickFiltered switch mode PSU performance

Trying the AIDA format power supply with the simple filters installed.

The detector is attached and HV of 200v@3.8uA

Using one channel from each FEE64 as a guide to compare performance. Using the Integrate analysis function Peak width.

With the bench power supply and the restored setup for the ASICs.

FEE64 #11:1.4.L:311, #12:2.8.L:183, #13:1.4.L:202, #14:1.4.L:342

Change to the filtered power supply

FEE64 #11:1.4.L:345, #12:2.8.L:414, #13:1.4.L:311, #14:1.4.L:476

Add Braid between the LEMO00 connectors on the two adaptor boards using "croc" clips.

FEE64 #11:1.4.L:172, #12:2.8.L:141, #13:1.4.L:106, #14:1.4.L:161

Change the shaping time of all the ASICs from 0.5uS to 5uS

FEE64 #11:1.4.L:128, #12:2.8.L:127, #13:1.4.L:119, #14:1.4.L:199

 

I think this means the AIDA power supply with the simple filters is equivalent or better than the bench supply.

Good news I think.....

It needs a more extensive test ( more channels ? )

  20   Wed Dec 3 12:13:03 2014 Alfredo EstradeIV curve with CAEN N1419
Measured IV curve for BB18 DSSD with new CAEN HV supply. Settings as in previous elog entry:

Detector bias CAEN N1419 Programmable HV Power Supply
  - FAGND isolated from AGND (AGND = NIM chassis ground)
  - floating HV supply, <5mV pp noise specification
  - configured + polarity, i.e. core to nnaida11 & nnaida12 MSL type BB18 n+n ohmic strips
                                braid to nnaida12 & nnaida13 MSL type BB18 p+n junction strips



Data (see attachment):
V [V]	I [uA]
3	1.34
6	1.62
9	1.81
12	1.97
15	2.1
18	2.21
21	2.31
24	2.39
27	2.46
30	2.52
35	2.61
40	2.68
45	2.73
50	2.77
55	2.8
60	2.82
70	2.86
80	2.91
90	2.94
100	2.97
110	3
120	3.06
130	3.12
140	3.18
150	3.26
160	3.34
170	3.43
180	3.53
190	3.62
Attachment 1: IV_dec14.PNG
IV_dec14.PNG
  19   Thu Nov 20 14:05:21 2014 Tom DavinsonAIDA Tests at STFC DL - PCS, TD
Configuration per Elog entries:

https://elog.ph.ed.ac.uk/AIDA/3
https://elog.ph.ed.ac.uk/AIDA/4

- except -

FEE firmware
  - reverted release 0xa4ed006
    as used at RIKEN due to stability/data issues with most recent releases

Detector bias CAEN N1419 Programmable HV Power Supply
  - FAGND isolated from AGND (AGND = NIM chassis ground)
  - floating HV supply, <5mV pp noise specification
  - configured + polarity, i.e. core to nnaida11 & nnaida12 MSL type BB18 n+n ohmic strips
                                braid to nnaida12 & nnaida13 MSL type BB18 p+n junction strips
  - configured bias voltage to 200V, max bias voltage 200V, max leakage current 20uA,
    trip 10s, ramp up/down 1V/s
  - bias 200V, leakage current 4.9-5.1uA 

ASIC parameters

  Default ASIC parameters (EXPERIMENT/AIDA/2014Aug13-13.44.58) except
  - shaping time 5us
  - slow comparator 20 (hex 14)

R31

  - 207Bi source (serial AD6201) mounted c. 3cm from MSL type BB18 DSSSD 
  - p+n junction side faces 207Bi source
  - source serial number *away* from DSSSD

  - Pulser BNC PB-5
    fall time 1ms
    rate 10Hz
    delay 250ns
    ampl 1.00000V
    polarity -
    pulse top tail
    atten x1

    positive polarity test input via EG&G Ortec 433A

R32

  - 207Bi source (serial AD6201) mounted c. 3cm from MSL type BB18 DSSSD 
  - p+n junction side faces 207Bi source
  - source serial number faces DSSSD

Attachments 1-20 from R32
Attachment 1: 1.png
1.png
Attachment 2: 2.png
2.png
Attachment 3: 3.png
3.png
Attachment 4: 4.png
4.png
Attachment 5: 5.png
5.png
Attachment 6: 6.png
6.png
Attachment 7: 7.png
7.png
Attachment 8: 8.png
8.png
Attachment 9: 9.png
9.png
Attachment 10: 10.png
10.png
Attachment 11: 11.png
11.png
Attachment 12: 12.png
12.png
Attachment 13: 13.png
13.png
Attachment 14: 14.png
14.png
Attachment 15: 15.png
15.png
Attachment 16: 16.png
16.png
Attachment 17: 17.png
17.png
Attachment 18: 18.png
18.png
Attachment 19: 19.png
19.png
Attachment 20: 20.png
20.png
ELOG V3.1.4-unknown