March 2013

From Hall A Wiki
Jump to: navigation, search

Date : 1st March 2013 (K.Allada)

For an accurate deadtime calculation we need to turn on TI readout. It will tell us how many triggers are received.

Things to do:

1. Turn on TI readout
2. Learn to access trigger counts from TI readout (Bryan said he maybe able to provide a routine to access trigger counts..check with him again)
3. Also check tiStatus() routine if it has anything useful in terms of trigger counts
4. After 1-3 is finished, check to see if FADC trigger counts match-up with TI counts. Otherwise we have problem?
5. Add both TI and FADC trigger match into the decoder and provide deadtime calculation

Date : 1st March 2013 (R. Michaels)

Scan of Deadtime and Asymmetry.

Using Kalyan's deadtime calculation, now embedded in my version of the code, I made a rate scan to see how the deadtime changed and what happened to the asymmetry.

Definitions
F+ = rate when helicity bit is true
F- = rate when helicity bit is false
Favg = DAQ rate (should be average of F+ and F-)
A_pred = (F+ - F-)/(F+ + F-) = predicted asymmetry
A_obs = observed helicity in data
DT = deadtime reported by Kalyan's algorithm
DNR? = if "Y", there were "Data Not Ready" printouts by the event list.  If "N" there were none.

Run ... avg F ... F+ ... F- ..... A_pred .... A_obs ..... DT ..... DNR?  
.......... kHz ..... kHz ........... % ....... % ......... %
2056 ... 280 ... 276.2 .. 285.9 .. 1.73 .... 1.01 ..... 0 ..... N 
2060 ... 239 ... 236.8 .. 246.3 .. 1.97 .... 2.35 ..... 0 ..... N
2063 ... 311 ... 306.8 .. 316.2 .. 1.51 .... 0.03 ..... 47.7 .. Y
2066 ... 330 ... 323.1 .. 332.3 .. 1.40 .... 0.01 ..... 53.3 .. Y
2068 ... 421 ... 418.3 .. 427.6 .. 1.10 .... 0 ........ 78.7 .. Y
2071 ... 218 ... 216.4 .. 226.1 .. 2.19 .... 1.22 ..... 0 ..... N
2073 ... 138 ... 135.8 .. 145.9 .. 3.58 .... 1.53 ..... 0 ..... N

Comments

The deadtime (DT) skyrockets at a critical frequency. I don't think I could get a small nonzero deadtime (e.g. 5%).

The presence of nonzero DT causes the Asymmetry to be completely diluted, by a far larger factor than you'd expect. Expect a dilution factor of 1-DT

A_obs often does not agree with A_pred. The other day (late Feb entry) this was also true, though one is sometimes greater and sometimes less than the other. Not clear why.

I am not convinced we are measuring the DT correctly. Need a second, redundant method.

Date : 7th March 2013 (K.Allada)

I think my deadtime calculation is not completely correct. I took several runs with different rates. I will analyze them later. The DT below is from existing method.

Run #   rate(KHz)       DT(%)   error
-----------------------------------
2102    139             0       no
2104    182             0       no
2105    244             0       no
2106    262             0       no
2107    282             0       no
2109    306             0       no
2110    316             1.2     yes
2108    330             13      yes
2111    371             40      yes
2112    402             54      yes
2113    431             64      yes
2114    474             76      yes
2115    509             84      yes
2116    542             89      yes
2117    595             97      yes
2118    637             86      yes
2119    721             100     yes