Difference between revisions of "Qweak GEM installation log book"

From New IAC Wiki
Jump to navigation Jump to search
Line 1,258: Line 1,258:
 
[[File:2010100110_0342.png | 200 px]]
 
[[File:2010100110_0342.png | 200 px]]
  
=Run 5551=
+
==Run 5551==
  
 
Starting a run using Hall C's CODA on cdaql6.
 
Starting a run using Hall C's CODA on cdaql6.

Revision as of 12:03, 2 October 2010

5/12/2010

Detector installation

The Qweak GEM detector has been installed in the doghouce in Hall-C and the HV was turned on. On the scope picture below is shown the GEM trigger out pulse, after it has been amplified and integrated with timing filter amplifier. The high voltage supply is placed in the doghouse with the other electronics.

GEMTrigOutinDoghouse-12-05-2010.jpgGEMTrigOutandGEMdetectorinDoghouse-12-05-2010.jpg

GEMSetUPinDoghouse-12-05-2010.jpg

Electronics

We have the NIM Bin with the following modules: Leading edge discriminator, timing filter amplifier(X2), Gumstix module.
GEMNIMBINandModulese-12-05-2010.jpgGEMGumstixandI2CNIMModuleinDoghouse-12-05-2010.jpg

Gas

The gas bottle filled with ArCO2 is placed outside the doghouse. We have two 90 ft shielded twisted ribbon cables next to region 1 area.


cables need to be routed about colimator 2.

GASbottleoutsidetheDoghouse-12-05-2010.jpgGEMShieldedRibbonCables-12-05-2010.jpg


Bubbler

R1 HallC Bubbler 7-27-10.jpg

5/13/2010

Met with Kelly Tremblay to discuss survey plans. Goal is to be ready for Qweak collaborators and survey crew to align detector on June 4. The "Fork" used to connect the GEM detector to the translator will be fiducialized for the laser survey system by mounting 4 targets on the fork. The request is to have the "Y" location surveyed in to 100 microns (this is essentially [math]\theta[/math]) . We desire the X-location to be surveyed within 250 microns. The Z - location beam upstream/downstream is the least critical.

DAQ computer name is : cdaql6


R1 ROC name : qwvme11 (129.57.168.81)

using the terminal server to login to the R1 ROC

telnet hctsv11 2008
qwvme11
telnet hctsv11 2006

or

telnet qwvme11

Gumstix and I2C


Brad Sawatzky: Contact for ordering gas ionfrastructure (bubbles, hose , valves,...)

5/14/2010

Gumstix sees the network now. It will be known as qwgemgumstix and have the IP address 129.57.168.91

We may also use the terminal server to login via the Gumstix's serial port but you must be logged into cdaql6 (or a computer on the same network as cdaql6)

telnet hctsv11 2007


Runcontrol runs the cMsg server.


Gumstix contains cMsg client and subscribes to the Runcontrol cMsg server. once receiving message from ROC it then send out a message of the current thrshold value which the ROC has subscribed to . This tells the ROC to pulse again.

Carl Timmer has a sample code in C.

use Send and Get

ROC is a cMsg client as well

ROC spawns a task upon userGo and starts stepping through Discriminator setting task start a pulse and sleeps until a Mutext comes then it sends a cMsg to Gumstix



search jlab.org
nameserver 129.57.32.100
nameserver 129.57.32.101
[cdaq@cdaql6 ~]$ nslookup cdaqfs
Server:         129.57.32.100
Address:        129.57.32.100#53

Name:   cdaqfs.jlab.org
Address: 129.57.168.10

auto eth0
iface eth0 inet static
        address 129.57.168.91
        netmask 255.255.252.0
        network 129.57.168.0
broadcast 129.57.171.255

is go to the next threshold setting.


Location of Qweak coda DAQ files

Readout lists cdaq@cdaql6 ~/coda]$ ls ~/qweak/coda26/crl/

[cdaq@cdaql6 crl]$ codamaster

ROC libraries

ls ~/qweak/libraries/vme/v1495_gem/

Error message from V1495.

-> v1495ReadEvent()
0x1ad8900 (tShell): v1495ReadEvent: Error: header for word 3 from data packet != 0xE
va

qwvme11 boot parameters

The firmware is set for 32 MHz but it looks like the actual clock is 31 MHz.


boot device          : dc
unit number          : 0 
processor number     : 0 
host name            : cdaql6.jlab.org
file name            : /usr/local/coda/kern/5.5/vx2400_u1
inet on ethernet (e) : 129.57.168.81:fffffc00
host inet (h)        : 129.57.168.46
user (u)             : cdaq
flags (f)            : 0x20 
target name (tn)     : qwvme11
startup script (s)   : /home/cdaq/qweak/coda26/boot/qwvme11.boot

5/15/10

LV1 accept to V1495 has to have a gate width at least 1 MCLK cycle less than 3 MCLK cycles.


We used cdaql6 to write several coda data files the the V1495 reading out 1 detect.

at MCLK=16MHz we created the files

v1495_28.dat.0 and v1495_29.dat.0

Run 28 was short, run 29 was very long.

I saw the following CHIP IDs in the data file but the thresholds are so high there were no hits

Card=0  ChipID=0xa6c
i = 14 
Card=1  ChipID=0x8ec
i = 28 
Card=2  ChipID=0x8ec
i = 42 
Card=3  ChipID=0x6ec
i = 56 
Card=4  ChipID=0x0
i = 70 
Card=5  ChipID=0x66c

Its seems Card 4 is not getting its ID recorded but its I2C is responding. Perhaps a failed card? We loer MCLK to 8 MHz no change.

Summary

Successes:

Two R1 detectors reside outside the Hall C doghouse. One detector was running in the doghouse and cosmic signals were observed which went away when turning the drift voltage down to equal the GEM preamplifier voltage (this is how we convince ourself that the signal is real without turning the detector completely off).

A data file was written using CODA v 2.6 installed on cdaql6 and the GW ROC. The MCLK signal however needed to be set to 16 MHz instead of 32 MHz. The V1495 was unable to "lock on " to the 32 MHz signal from the G0 clock. It is not understood why at this time. While sampling the data at 16 MHz is not a show stopper we will try to find a way to operate at 32 MHz. The same V1495 was able to lock onto our 32 MHz pulser at ISU without a problem.

A GEM detector was mounted on the rotator and was able to rotate 360 degrees freely. There was some concern that the Breakout board would hit a bolt coming up from the floor which secures the first collimator. There is at least a 3 inch gap between this bolt and the breakout board at the point of closest approach. A substantial amount of the bolt thread extends well beyond the nut. A request will be made to cut off the excess bolt that extends beyond the nut.

Failures:

We are unable to record the VFAT output in the V1495 using the ribbon cables provided by JLab. The V1495 was no longer able to recorded the output of 3 VFAT cards when we switched from our 4 foot long, shielded, flat ribbon cables to JLab's 100 ft long rounded ribbon cables. We have seen this before. We had similar problems at ISU and found that they went away when a twisted pair FLAT ribbon cable was used. Signal integrity becomes important at the 40 MHz frequencies.


Path forward:

We will try to debug breakout board with VFAT electronics, the V1495, and two JLab shielded ribbon cables at ISU to determine if JLab's cables are not usable. We did successfully test the readout using 100 ft FLAT twisted pair cables during ISU beam tests. If the FLAT cables must be used then we will need to coordinate with Klaus on the cable holder to determine if the holder can accommodate flat cables or if we can use the rounded cables for the last [math]X[/math] meters of slack used by the cable holder.


6/13/10

R1 Nauvoo 6-13-10.jpg

7/29/10

R1 Nauvoo 7-29-10 RadTestVFAT.jpg R1 Nauvoo 7-29-10 RadTestVFAT Anoted.jpg

8/4/10

PRETRGe&EN1 scaler in Hall C counting house pannel port 6.


The Trig out of GEM A and B went into chanels 4 & 5 of the same scaler used for Alena's scintillator which records it values in the ROC file bank ID0x0403

Power strip control to reboot Hall C equipment can be accessed from the counting room computer

https://hallcweb.jlab.org/wiki/index.php/Hall_C_Network

Check V1495

To check if the V1495 is installed I logged into the ROC from cdaql1

[cdaq@cdaql1 ~]$ telnet qwvme11
->v1495Init(0x09330000)


The V1495 address was set to 0811 so I changed it to 0933


Now I see that it is initializing

-> v1495Init(0x09330000)
0x1b09070 (tShell): v1495Init: v1495 Module has been successfully initialized.

0x1b09070 (tShell): v1495 module has been reset: 

value = 0 = 0x0

It seems I have the old I2C gumstix to Breakboard card and not the right RJ45 connector to allow me to talk I2C to the VFAT card (unless the VFAT card has gone bad). Effort to make my own cable according to Tamuna's pinout chart failed.

7/5/10

DAQ

Paul and I were able to get CODA 2.6.1 to initialize the V1495 upon PRESTART. Apparently there is a problem running more than 1 DAQ at a time on different computers (perhaps they are trying to use the same rcServer?).

Detector

A GEM trigout signal is going upstairs to the scope. The timing amplifier downstairs is set to integrate the pulse over 100 ns. Is this why I see 600 ns Comsic pulses? I will check this with beam tomorrow morning.

I will use the discriminated output of HALO3 to determine if there is beam coming down the beamline and LUMI3 to determine if a target is in.

The HV for the above monitors may be observed through EPIC on cdaql6 with the following commands

  1. login to cdaql6
  2. ssh cvswrks@cdaql6
  3. /net/cdaqfs/home/EPICS/dvlepics/llapp/CaenHV/1-0/QWEAK/tk/hv.tcl

First Beam

I saw signals associated with an electron beam into Hall C for the first time today. The beam was being tuned and the detector was out of position so any signals were mostly background. The HV was -3600 Volts on the drift and -3300 Volts on the GEM preamplifier. The Trigout pulse was amplified in the doghouse by an Ortec timing amplifier set to integrate the signals over a 100 ns period.

7/6/10

GEM Timing Amp

The Ortec timing amplifier used to send the GEM output upstairs has an integrate time of 100 ns. The Phillips discriminator has a maximum output width of about 100 ns and we do see double pulsing sometimes so be careful. The max rate for a 50 ns GEM pulse is 20 MHz but the preamp width of 600 ns keeps us below 1 MHz, and the discriminator width of 100 ns keeps us below 10 MHz.

Qweak R1 DiscrTrigout 8-5-10 1.png Qweak R1 DiscrTrigout 8-5-10 2.png

With a 1 mil Aluminum target, the 10 MHz max rate may be at a beam current of 50 nA.

Add GEM scaler to MAP

login to cdaql4

cd $QWANALYSIS/Tracking/prminput/

The file

 detectors.map 

describes all the detectors used below are two relevant examples

[QwGasElectronMultiplier]
 name = R1
 map = qweak_R1.map
 geom = qweak_new.geo
[QwTriggerScintillator]
 name = TS
 map = qweak_trigscint_channel.map
 geom = qweak_new.geo
 mask = 0xffff

The scalers used for the GEM trigout pulse are plugged into the trigger scintillator scalers so I edited the file to look like this

sca_bank=0x0403
! module.type  module.num  chan.num, det.type, det.name
  SIS3801, 0,  0, trigscint, ts2m_sca
  SIS3801, 0,  1, trigscint, ts2p_sca
  SIS3801, 0,  2, trigscint, ts1m_sca
  SIS3801, 0,  3, trigscint, ts1p_sca
  SIS3801, 0,  4, trigscint, GEMTrigOut_Naovoo_sca
  SIS3801, 0,  5, trigscint, GEMTrigOut_Urim_sca
  SIS3801, 0,  6, trigscint, ts2mt_sca
  SIS3801, 0,  7, trigscint, ts1mt_sca

The ROOT files are stored in

cd $QW_ROOTFILES

and named as QWEAK_runNumber.000.root


To reanalyze the tracking data without doing tracking go to the data directory

cd $QW_DATA/
 qwtracking -r 724 --QwTracking.disable-tracking


The Scaler is read out at fixed time intervals but those intervals can change depending on helicity flip rate and if a "fake" helicity flip rate is being used.

R1 Timing

Octant5 QweakScint R1Naovoo 8-6-10 Timing 1.png

200 px

200 px

200 px

200 px

R1 rate -vs- beam current

Run # Scint Naovoo


19-08-2010

Took detector apart. GEM foils(all of them) are bunt. Some of the strips have discoloration, they have burnt spots.

The images below show all the GEM foils and PC board.


GEM1-19-08-2010.jpgGEM2-19-08-2010.jpg
GEM3-19-08-2010.jpgGEM4-19-08-2010.jpg
GEM5-19-08-2010.jpgGEM6-19-08-2010.jpg
GEM7-19-08-2010.jpgGEM8-19-08-2010.jpg
GEM9-19-08-2010.jpgGEM10-19-08-2010.jpg
PCB1-19-08-2010.jpgPCB2-19-08-2010.jpg
300px300px


During the beam tuning at JLab, when all tracking chambers were in place, I saw the following on trigout with the detector off.

JLab Aug6 2010 BeamTune 10ma.jpg

Channel 3 (purple) is the trigout signal from the GEM detector. I believe Channel 2 was the Qweak scintillator and Channel 1 was a Halo monitor. I have never seen such an output from the GEM detector when exposed to beam. It seems we are unable to have the GEM detector in place when the pulsed 10 mA beam is tuning. I suspect this killed the detector on Aug 6.


20-08-2010

Gas was flowing through both detectors today. In order to reduced the pick up noise, It was suggested to wrap detectors into the aluminum foil.

Tomorrow is a power shutdown in EEL, CEBAF and some other building. I will be unable to work there. I will get the scaler from counting room.

Urim

Below are the scope images of the noise before and after aluminum foil:

BeforeAlfoilnoise.pngAfterAlfoilnoise.pngAfterAlfoilnoise 1.png

Signals from the detector are following:

AfterAlfoilsignal.pngAfterAlfoilsignal 1.png


URIMinEEL.jpg

Nauvoo

Turned Nauvoo on today. Foils were changed yesterday. When looking at TrigOut instead of seeing the positive pulse i am getting negative pulse, and no signal on strips. The last GEM foil acts like an anode(it collects the charge). I forgot to take the scope picture, but thats what i observed.


22-08-2010

Changed the shorted GEM foil on Nauvoo, but still no positive signal on TrigOut. I saw negative signal.

23-08-2010

Today worked on I2C. Gumstix, I2C board and power supply were installed in the NIM module. NIM module is in the NIM bin. The breakout box and two VFATs(64 and 112) are in the box under the NIM bin.

GumstixI2CNIMModule.jpgGumstixI2CNIMModule 1.jpg


Got Timing Filter Amplifier, couldnt find scaler. There was no use for integrator on Timing Filter Amplifier.

Nauvoo detector is open right now. I will apply voltage on GEM tomorrow and check the voltages again across the GEM foils.

24-08-2010

Urim measurements

Got scaler and discriminator. Made measurements of GEM drift voltage vs rate. Used only cosmic rays.

The result is shown below:

GEMDRIFTHVvsRate 24-08-2010.jpg


GEMDRIFTHVvsRate 25-08-2010.jpg


The rate only doubled Dr. Forest. I did it for 3270 Volts.

Urim should be ready to install in Hall C after you try a source and wrap it in tin foil. Cut an opening in the tin foil for a window.


Fe-55 Source use

Activity of Gamma, x-ray source. [math]300 \mu C \times \left ( 3.7 \times 10^{10} decays/sec \right ) = 1.1 \times 10^7 decays/sec = A_0[/math] as of 6/24/04.


Half life = 2.73 years

[math]A = A_o e^{-\lambda t} = 1.1 \times 10^{7} decays/sec e^{-6/2.73} = 1.2 \times 10^6 decays/sec[/math]


[math]E_{\gamma} = 126[/math] keV

TORI Data (1999) Gammas from 55Fe (2.73 y 3)

Eg (keV) Ig (%) Decay mode 125.95 1 1.28E-7 2 e



X-rays from 55Fe (2.73 y 3) E (keV) I (%) Assignment 0.556 0.037 10 Mn Ll 0.568 0.025 6 Mn Lh 0.637 0.028 7 Mn La2 0.637 0.25 6 Mn La1 0.640 0.0022 6 Mn Lb6 0.648 0.19 5 Mn Lb1 0.720 0.011 3 Mn Lb4 0.720 0.017 5 Mn Lb3 5.770 6.9E-06 4 Mn Ka3 5.888 8.5 4 Mn Ka2 5.899 16.9 8 Mn Ka1 6.490 1.01 5 Mn Kb3 6.490 1.98 10 Mn Kb1 6.536 0.00089 5 Mn Kb5 6.539 8.5E-08 5 Mn Kb4



NIST data tables says:


A .125 MeV photon has a Range in copper of = [math]3.2 \times 10^{-2} g/cm^2[/math]

Density Copper = [math]8.92 g/cm^3[/math]

Range = [math]3.2 \times 10^{-2} g/cm^2 / 8.92 g/cm^3 = 3.5 \times 10^{-3} cm = 1.4 \times 10^{-3} inches = 1.4[/math] mils

How thick is the GEM copper cathode?


Definition of Range:

Def of Range (R)
The distance traveled before all the particles energy is lost.
[math]R \equiv \int_0^T \frac{dE}{\frac{dE}{dx}}[/math]
= theoretical calculation of the path length traveled by a particle of incident energy [math]T[/math]
Note units: [math]\left [ R \right ] = \frac{g}{cm^2} ; \left [ \frac{dE}{dx} \right ] = \frac{MeV \cdot cm^2}{g}[/math]


At 0.126 MeV

[math]\frac{dE}{dx} = 2.387 MeV cm^2/g = 21.292 MeV/cm[/math]

If the copper is 5 microns thick then

[math]E_{loss} = 21292 keV/cm \times 5 \times 10^{-3} cm = 106 keV \Rightarrow [/math]photon energy would be about 20 keV when it sees drift region

What is Cathode thickness?

Is the Fe-55 source sealed or open. Sealed source would attenuate photons more.


The fraction of photons surviving a distance x is given by

[math]\frac{I}{I_0} = e^{-\mu x}[/math]

where

[math]\mu[/math] = total absorption coefficient = 1/(mean free path) = [math]\frac{N \rho}{A} \sigma[/math]


N = Avagadros number [math]\rho[/math] = density of copper A = molar weight [math]\sigma[/math] = cross-section per atom


A 6 keV photon has [math]\mu/\rho = 115.2 cm^2/g \Rightarrow \mu[/math] = 1027.6 /cm


A 126 keV photon has[math] \mu/\rho=~0.3 cm^2/g \Rightarrow\mu [/math] ~ 3 /cm

[math]\left . \frac{I}{I_o}\right |_{6 keV} = e^{-1027.6/cm \times 50 \times 10^{-3} cm} = 4 \times 10^{-23}[/math]

[math]\left . \frac{I}{I_o} \right |_{126 keV} = e^{-3/cm \times 50 \times 10^{-3} cm} = 0.86[/math]

If the copper cathode is 5 microns and not 50

[math]\left . \frac{I}{I_o}\right |_{6 keV} = 6 \times 10^{-3}[/math]

[math]\left . \frac{I}{I_o} \right |_{126 keV} = 0.98[/math]

the link below takes you to the mass attenuation coefficients for copper

http://physics.nist.gov/PhysRefData/XrayMassCoef/ElemTab/z29.html


X-rayPhotonAttenuation.gif


The 2nd column is the mass attenuation coefficient [math]\mu/\rho[/math] and the third column is the energy absorption coefficient [math]\mu_{en}/\rho[/math]

Copper Z = 29

____________________________________

     Energy                
      (MeV)      (cm2/g)     (cm2/g)
____________________________________

   1.00000E-03  1.057E+04  1.049E+04 
   1.04695E-03  9.307E+03  9.241E+03 
   1.09610E-03  8.242E+03  8.186E+03 
L1 1.09610E-03  9.347E+03  9.282E+03 
   1.50000E-03  4.418E+03  4.393E+03 
   2.00000E-03  2.154E+03  2.142E+03 
   3.00000E-03  7.488E+02  7.430E+02 
   4.00000E-03  3.473E+02  3.432E+02 
   5.00000E-03  1.899E+02  1.866E+02 
   6.00000E-03  1.156E+02  1.128E+02 
   8.00000E-03  5.255E+01  5.054E+01 
   8.97890E-03  3.829E+01  3.652E+01 
K  8.97890E-03  2.784E+02  1.824E+02 
   1.00000E-02  2.159E+02  1.484E+02 
   1.50000E-02  7.405E+01  5.788E+01 
   2.00000E-02  3.379E+01  2.788E+01 
   3.00000E-02  1.092E+01  9.349E+00 
   4.00000E-02  4.862E+00  4.163E+00 
   5.00000E-02  2.613E+00  2.192E+00 
   6.00000E-02  1.593E+00  1.290E+00 
   8.00000E-02  7.630E-01  5.581E-01 
   1.00000E-01  4.584E-01  2.949E-01 
   1.50000E-01  2.217E-01  1.027E-01 
   2.00000E-01  1.559E-01  5.781E-02 
   3.00000E-01  1.119E-01  3.617E-02 
   4.00000E-01  9.413E-02  3.121E-02 
   5.00000E-01  8.362E-02  2.933E-02 
   6.00000E-01  7.625E-02  2.826E-02 
   8.00000E-01  6.605E-02  2.681E-02 
   1.00000E+00  5.901E-02  2.562E-02 
   1.25000E+00  5.261E-02  2.428E-02 
   1.50000E+00  4.803E-02  2.316E-02 
   2.00000E+00  4.205E-02  2.160E-02 
   3.00000E+00  3.599E-02  2.023E-02 
   4.00000E+00  3.318E-02  1.989E-02 
   5.00000E+00  3.177E-02  1.998E-02 
   6.00000E+00  3.108E-02  2.027E-02 
   8.00000E+00  3.074E-02  2.100E-02 
   1.00000E+01  3.103E-02  2.174E-02 
   1.50000E+01  3.247E-02  2.309E-02 
   2.00000E+01  3.408E-02  2.387E-02 

Setting on Amplifier and discriminator:

Amplification is X20 and 10 on a nub. Integration=20ns and diff=out. Pulse divided, one and goes to discriminator and the other one into the scope. The discriminator threshold is set to 45 mV.

Nauvo

High Voltage distribution for GEM.


GEM HV Dist Net.jpg

Applied 500 Volts on GEM.

The measured voltage on each side of the each GEM foil is presented in a table.


GEM Foil Measured Voltage(Volts) Nauvoo Measured 10 x 10 cm Board Voltage
VGem in 500 500
G1T 256 248
G1B 422 473
G2T 148 232
G2B 237 415
G3T 78 217
G3B 104 371


I was expecting the voltage to decrease with respect to ground as you go down the voltage divider.

It is decreasing. By G3 i mean the last GEM foil.


27-08-2010

Got CAT5 cable for I2C. Need connectors.

Changed resistors on HV board of Nauvoo, still no luck. Had to take open Urim, to check the voltage distribution, it is the same as on Nauvoo.

Dont know what is the reason, the foils are new.

Instead of positive pulse getting negative pulse on trigout again.

30-08-2010

Nauvoo

Works since yesterday. Changed foils.

Nauvoo 30-08-2010.jpgNauvoo 30-08-2010 1.jpg

Voltage = 3475/3200 Volts

Amplification= X20, 12.5 on a nub.

Integration=20ns

Diff=out

Discriminator threshold = 80 mV

Time (mints) # Counts Rate (Number of Events/sec)
13 1002 1.28
16 1233 1.28
14 914 1.1


[math]Rate = 1.22 \pm 0.07 [/math](Numberof#/sec)

Urim

UrimVerticalPosition 30-08-2010.jpg


Voltage setting on Urim = 3245/2945 Volts


Time (mints) # Counts Rate (Number of Events/sec)
11 1357 2.056
7 859 2.045
7 862 2.052


Vertical vs Horizontal

Position Rate (Number of Counts/sec)
Vertical [math]Rate = 2.05 \pm 0.004[/math]
Horizontal [math]Rate = 2.15 \pm 0.07[/math]

The bracket is attached to Urim.

UrimBracket 30-08-2010.jpg

Remaining tasks

bubbler holder , need 2 more shielded ribbon cable, new aluminum foil for detector in order to shield it.

High Voltage Supply: The channel number 2 on hv supply doesnt go above 3000Volts. Suggest, to use 0 and 1 channels for Nauvoo and 3&&2 for Urim.

There is only one new breakout box in Hall, need to bring second one.


1.)check cosmic rate on both detectors and measure noise ( max 10 mV peak to peak)

Detector Drift HV GEM HV
Urim -3245 -2945
Nauvoo -3450 -3150

2.) Attach adapter boards

3.)I2C checkout

4.) Look into Al shielding

5.) install shielded ribbon cables, work on readout

6.) install bubbler if still not done.

Co-60 source

A Co-60 source was placed on top of the GEM detector kapton foil window. The button source activity was 0.6 microCurie in 2004. The source generated a rate of 70 Hz.


Activity of Gamma source. [math]6 \times 10^{-7} C \times \left ( 3.7 \times 10^{10} decays/sec \right ) = 2.2 \times 10^4 decays/sec = A_0[/math] as of 6/24/04.

Half life = 5 years

[math]A = A_o e^{-\lambda t} = 2.2 \times 10^{4} decays/sec \times e^{-6/5} =6686 Hz [/math]


According to http://ie.lbl.gov/toi/nuclide.asp?iZA=270060

Co-60 activity is from mainly 2 photons 1173.237 keV and 1332.501 keV.


A 1.2 MeV photon has[math] \mu/\rho=0.0526 cm^2/g \Rightarrow\mu =[/math]0.465 /cm

[math]\left . \frac{I}{I_o}\right |_{1.2 MeV} = e^{-0.465/cm \times 50 \times 10^{-3} cm} = 0.977[/math]

If the above is correct , the Co-60 source is emitting 1.2 MeV photons at a rate of 6.5 kHz.


9-18-10

Use cdaq@cdaql6 to readout V1495.


terminal server port

To get to qwvme11

telnet hctsv7 2006


To go to Gumstix

telnet hctsv11 2005


Checking I2C controls

ssh root@qwgemgumstix

cd bin

ports 112 and 64 have VFAT cards on them

flipping sleep block for VFAT at I2C address 64

 echo "p 64 0 0 flip" | ./flipbit.arm
 echo "p 112 0 0 flip" | ./flipbit.arm


The 2 VFAT cards are responding.

My SCSI doesn't seem to work anymore with my powerbook. Try to debug tonight.

I got the DAQ running on cdaql6.

I am sending a trigger down to the V1495 which triggers the VFAT cards.


I got the error message on the ROC


interrupt: v1495ReadEvent: Error: header for word 3 from data packet != 0xE

EB1 crashed. I am triggering at about 200 Hz.

Wrote data file

Paul King paid me a visit and corrected my CODA choices so I could write a file. Apparently I had chosen Session and Run configuration wrong


Proper CODA settings for standalone V1495 runnging


Session = cdaq COOL configureation = V1495_l6


To start DAQ

1.) run codamaster

2.)choose v1495_l6 from the EXPID menu presented by coda master

3.) launch all the components

4.) choose "V1495_l6" from the session menu in runcontorl

5.) select the "cool" menu from the "Configuration" menu.

then select "V1495_l6" from the popup menu

6.) follow the usual download, prestart , and run


wrote the data file


[cdaq@cdaql6 ~]$ ls -lh /local/data1/v1495_l6_5424.dat.0 -rw-r--r-- 1 cdaq c-cdaq 64K Sep 18 19:50 /local/data1/v1495_l6_5424.dat.0

All is not perfect. I get the error message

interrupt: v1495ReadEvent: dataFIFO is empty


It looks like the VFAT is missing some of the triggers I send it when I look on the scope.

Try to debug tomorrow by doing single triggers and use the functions

v1495DataReady(0

the above function should return the number of events waiting to be read out. So hit the trigger button and make sure the above function returns the value of "1"

Then use the command


-> v1495StatusPrint

0x1b090b0 (tShell): V1495[0]: #B[24] #F[1/131] B/s[24] F/s[1]
0x1b090b0 (tShell):   LastCap[12]: 0x1b090b0 (tShell): A2AC 0x1b090b0 (tShell): C720 0x1b090b0 (tShell): 0A71 0x1b090b0 (tShell): 0000 0x1b090b0 (tShell): 0000 0x1b090b0 (tShell): 0000 0x1b090b0 (tShell): 0000 0x1b090b0 (tShell): 0000 0x1b090b0 (tShell): 0000 0x1b090b0 (tShell): 0000 0x1b090b0 (tShell): 0000 0x1b090b0 (tShell): 907D 0x1b090b0 (tShell): 
0x1b090b0 (tShell): Event Count: 114 ; Chip ID : 0xA71
0x1b090b0 (tShell): value = 32 = 0x20 = ' '
-> V1495[1]: #B[0] #F[0/0] B/s[0] F/s[0]
0x1b090b0 (tShell):   LastCap[0]: 0x1b090b0 (tShell): 
0x1b090b0 (tShell): V1495[2]: #B[0] #F[0/0] B/s[0] F/s[0]
0x1b090b0 (tShell):   LastCap[0]: 0x1b090b0 (tShell): 
0x1b090b0 (tShell): V1495[3]: #B[0] #F[0/0] B/s[0] F/s[0]
0x1b090b0 (tShell):   LastCap[0]: 0x1b090b0 (tShell): 
0x1b090b0 (tShell): V1495[4]: #B[0] #F[0/0] B/s[0] F/s[0]
0x1b090b0 (tShell):   LastCap[0]: 0x1b090b0 (tShell): 
0x1b090b0 (tShell): V1495[5]: #B[24] #F[1/131] B/s[24] F/s[1]
0x1b090b0 (tShell):   LastCap[12]: 0x1b090b0 (tShell): A2AC 0x1b090b0 (tShell): C720 0x1b090b0 (tShell): 5CEA 0x1b090b0 (tShell): 0000 0x1b090b0 (tShell): 0000 0x1b090b0 (tShell): 0000 0x1b090b0 (tShell): 0000 0x1b090b0 (tShell): 0000 0x1b090b0 (tShell): 0000 0x1b090b0 (tShell): 0000 0x1b090b0 (tShell): 0000 0x1b090b0 (tShell): 74A8 0x1b090b0 (tShell): 
0x1b090b0 (tShell): Event Count: 114 ; Chip ID : 0xCEA

You should see chip IDs like above.

9/19/10

Missing triggers

I noticed yesterday that some triggers did not return data packets. Let's try to debug this.

I have 2 VFAT cards in port 64 and 112. As seen from yesterday using the v1495 library function v1495StatusPrint() on the ROC The CHIP ID's are 0xCEA and 0xA71. This agrees with what I2C is telling me.

I will now give the Readout one trigger at a time and check if the V1495 has any data on it using the

v1495DataReady()

function.

First run the script VFAT.setup from the qwgemgumstix. The script is in the subdirectory /home/root/bin

/home/root/bin/VFAT.setup


Now I will work from the ROC.

First Initialize the V1495

 -> v1495Init(0x09330000)
0x1b08930 (tShell): v1495Init: v1495 Module has been successfully initialized.

0x1b08930 (tShell): v1495 module has been reset: 

value = 0 = 0x0

Now I reset the v1495 module to clear all its buffers

-> v1495Reset()
0x1b08930 (tShell): v1495 module has been reset: 

value = 0 = 0x0

Now Check to see if there is any data before I push the single trigger button on the gate generator.

-> v1495DataReady()
value = 0 = 0x0

Now push the trigger button once

-> v1495DataReady() value = 1 = 0x1


Now I check what is in the buffer using

-> v1495StatusPrint()
0x1b08930 (tShell): V1495[0]: #B[24] #F[1/2] B/s[24] F/s[1]
0x1b08930 (tShell):   LastCap[12]: 0x1b08930 (tShell): AE46 0x1b08930 (tShell): C010 0x1b08930 (tShell): 0A71 0x1b08930 (tShell): 0000 0x1b08930 (tShell): 0000 0x1b08930 (tShell): 0000 0x1b08930 (tShell): 0000 0x1b08930 (tShell): 0000 0x1b08930 (tShell): 0000 0x1b08930 (tShell): 0000 0x1b08930 (tShell): 0000 0x1b08930 (tShell): 1C38 0x1b08930 (tShell): 
0x1b08930 (tShell): Event Count: 1 ; Chip ID : 0xA71
0x1b08930 (tShell): V1495[1]: #B[0] #F[0/0] B/s[value = 0] F/s[032]
0x1b08930 (tShell = 0x):   LastCap[020]: 0x1b08930 (tShell = '): 
0x1b08930 ( tShell): V1495[2]: #B['0] #F[0/0] B/s[
0] F/s[0]
0x1b08930->  (tShell):   LastCap[0]: 0x1b08930 (tShell): 
0x1b08930 (tShell): V1495[3]: #B[0] #F[0/0] B/s[0] F/s[0]
0x1b08930 (tShell):   LastCap[0]: 0x1b08930 (tShell): 
0x1b08930 (tShell): V1495[4]: #B[0] #F[0/0] B/s[0] F/s[0]
0x1b08930 (tShell):   LastCap[0]: 0x1b08930 (tShell): 
0x1b08930 (tShell): V1495[5]: #B[24] #F[1/2] B/s[24] F/s[1]
0x1b08930 (tShell):   LastCap[12]: 0x1b08930 (tShell): AE46 0x1b08930 (tShell): C010 0x1b08930 (tShell): 5CEA 0x1b08930 (tShell): 0000 0x1b08930 (tShell): 0000 0x1b08930 (tShell): 0000 0x1b08930 (tShell): 0000 0x1b08930 (tShell): 0000 0x1b08930 (tShell): 0000 0x1b08930 (tShell): 0000 0x1b08930 (tShell): 0000 0x1b08930 (tShell): F8ED 0x1b08930 (tShell): 
0x1b08930 (tShell): Event Count: 1 ; Chip ID : 0xCEA

I see the CHIP ID's which I saw when using the I2C interface.

Note
Data is still wiating to be readout, doing the above function did not alter the V1495 buffers

-> v1495DataReady() value = 1 = 0x1


To move the data out of the v1495 buffers you can do a ReadEvent


-> v1495DataReady()  
value = 1 = 0x1
-> v1495ReadEvent()  
value = 84 = 0x54 = 'T'
-> v1495DataReady()  
value = 0 = 0x0
-> v1495ReadEvent()  
0x1b08930 (tShell): v1495ReadEvent: dataFIFO is empty
value = 0 = 0x0


I sent trigger to the v1495 and monitored the scope output.

Whe I started I observed that about 30% of the triggers were missed as seen on the scope.

Changing the shielded cable to an unshielded seemed to drop that to 10%. Perhaps the missed triggers are cable related.

I think I will put connectors onto the new shielded ribbon cable and see if things improve.

Rad damage to VFAT chip?

I took out the two working VFATs and inserted a VFAT card which was in the R1 hut during the summer commissioning run.


Observation
I2C was still working, I could set registers, but I did not observe any LVDS output (I believe it was not working before though).

Test 2nd breakout box

NEED TO BRING MORE JUMPERS
Tamuna's NIM Module only has 1 power output. Should we tee it off to supply 2 breakout boxes, I am not sure if it can supply the current. May need to test


I think you cant tee it.

It depends on how much current the power supply is rated for. I think we need at least 1.2 mA per breakout board. So if the power supply delivers 3 mA and maintains 2.5 volts we would be able to tee it.

I wonder if Warren put in the voltage protection diodes in the latest version of the breakout board?

I think I also need to work on the I2C control of 2 boards with one gumstix or I could ask Tamuna to build another NIM module.

Test 2nd breakout box in R1 Hut

It seems there is a lot of pickup on the flat ribbon cable (peak-peak noise of about 400 mv with and RMS of 40 mv).


R1Hut LVDS FlatRibbonCableNoise 9-19-2010.png


Now hook a ground wire between the scope and a Ground pole in Hall C.

BNC trig out cable is on Channel 1, not hooked to anything. Grounding the scope reuces the noise to 60 mV peak-peak.

The unshielded ribbon cable is hooked to Channel 2

GoundScope2HallC BNCCH1 FlatRibbonCableCH2Noise 9-19-2010.png


BNC trig out cable is on Channel 1, not hooked to anything

The unshielded ribbon cable is hooked to Channel 2


The shield from a shielded ribbon cable is attached to Scope.


GoundScope2CableShield BNCCH1 FlatRibbonCableCH2Noise 9-19-2010.png

Shielded cable ungrounded

9-19-2010 856.png

Shielded cable grounded

9-19-2010 857.png


16 MHz LVDS clock on either shielded flat fibbon cable or unshielded with shielded ribbon cable grounded to scope

9-19-2010 904.png

16 MHz LVDS clock straight out of V1495

9-19-2010 939.png

Conclusion
The clock pulse is being attenuated by a factor of 3. You need 200 mV differentials to drive LVDS and both cables attenuate the pulse to below 130 mV.
The grounding the ribbon cable shield to the scope drops the noise from 400 to at least 30 mV. Similar noise reduction was observed if you only use shielded cable in the R1 hut area.

9/20/10

Made new shieled ribbon cables to take signals from breakout board to VFAT cards

started taking a run with VTAS plugged into 16 and 112

/local/data1/v1495_l6_5429.dat.0

I think the FIFO empty messages started killed the DAQ after about 200 events.

The above missing triggers is because the trigger pulse needs to have a width that is at least 1.5 MCLK cycles

maybe its because the trigger pulse was not 1.4 clock pulses wide.

Make HClog entry for Paul King

9/24/10

Cat 6 -vs- ribbon cable attenuation

The 28 guage ribbon cable wire attenuates a 20 MHz signal 4.8 dB/100 ft.

File:BELDEN WIRE AND CABLE 214-3078.PDF

The scope observations from 9/19/10 suggest that

dB = 20 log(400 mV/120 mV) = 10.45 dB/100 ft > 4.8 dB/100 ft?

Cat 6 attenuates 20 MHz signal 2.2 dB/100 ft (careful units are in meters in document below)

File:Cat6Attenuation 060-490GY.pdf

V1495 connector pin assignment

VFAT2V1495Break1.png

9/27/10

A MCLK of 6.3 MHz or less will drive the one VFAT card on the breakout box. The scope picture below shows the output at the break out box from a VFAT card installed at address 112.

20100927 1019.png

Zooming in to the MCKL pulse and comparing what comes out of the V1495 (MCLKin) and out of the 100 FT JLab shielded, round ribbon cable (MCLKout)


20100927 1033.png

I notice the V1495 output at JLab has a peak-peak value of 420 mV. Perhaps we can run at a higher frequency using the V1495 at JLab.


Now lets try installing 6 VFAT card to check that the V1495 output is not pulled down using the extra cards. I believe the V1495 delivers a separate MCLK pulse to each VFAT card. So this is a test of the V1495's drivers for each I/O channel.

The VFAT output on the breakout board still worked with all 6 VFATs being driven by the V1495.

Now lets attach the long cable to the digital output from the Breakout box and measure its attenuation

Below is a measurement off the breakout box

20100927 1044.png

Below is a measurement out of the shielded round ribbon cables from JLab.

20100927 1050.png

There is less attenuation but the capacitance is clearly rounded the logic pulse. Is this too much to prevent flipping a V1495 input? Probably not if this worked before.

9/29/10

Checking out detectors at JLab.

Simone tells me they put HV on both Detectors last Friday and Nauvoo appeared to spark.

Today I see Nauvoo sparking at 2600 Volts on GEM.

Urim appears to be working well still.

Urim is attached to the Hall C rotator on SLider A and the trigout signal is being sent directly to the upstairs DAQ shed.

To see a ~1Hz rate I have set the HV to

Detector Drift HV GEM HV
Urim (GEM A) -3400 -3100

Urim HallC 20100929 1227.png

After Lunch I will put Urims trig out signal into the timing AMplifier Tamuna set up and look for signals. For now I lower the voltage to 3250:2950.


I am leaving Nauvoo at 2800:2500.

I connected up amplifer and set discriminator to 60.0 mV and saw a 2 Hz rate when using HV = 3400:3100.

The signal out of the amplifier looks like

AmpOut20100929 1524.png

Readout

Now I work on readout.

I set Agilent to 6 MHz and download new firmware to qwvme11.


Pulled the round, shielded , ribbon cables to R1 and installed 6 VFAT cards on Urim.


LVDS data out pulse seen on V1495 copy using rounded ribbon cables.

VFATdataOut 20100929 1525.png

9/30/10

Working on setting discriminator levels on the VFAT.

Spent a lot of time looking at signals.

Took scope picture of noise from the sliders. Channel 3 is connected directly to a breakout board mounted to the GEM detector but not plugged into LVDS signals. THe power is connected to the breakout board and thus a ground through the doghouse racks.

With the sliders off I see the following. The red trace is a FFT of channel 3.

20100930 1625.png

Turn on the sliders using the computer (this puts voltage on them) and the signal gets worse

20100930 1628.png

The frequency of the beats seems to be about 24kHz


The above noise prevented me from seeing the digital output of the VFATs when measured at the breakout box. They were there but the 200 mV signals were hard to see with the 128 mV 240 kHz noise signal.

I decided to look at the copies of the VFAT data out signals which come out on the inner cable in the V1495's port C. I could clearly turn VFAT cards off individually and set the threshold by hand. I set 4 out of the 6 VFAT cards to a noise level. For some reason there wasn't a digital out from the V1495 for chips at I2C addresses 80 nor 96.

Tomorrow try to check the 2 remaining VFATs. May need to swap cards or breakout boards.

The I2C communication appears to fails sometimes. The VFATs are still running suggesting that the problem is at the gumstix level. Perhaps the terminal server connection was not responsible for the failure yesterday.

10/1/10

The above I2C problem appears to be due to an undervoltage to the Breakout box. I turned up the voltage to 3.1 Volts instead of 2.5. The LED is still not on but the I2C to the VFAT is more stable.

R1 gas consumption

I observed that the R1 gas bottle gauge changed by 50 Psig over the last 24 hour period.

Self trigger timing

Let's play with the latency of the chip to see if we have cosmic hits.

We turned Urim up to 3400:3100, say signals at about 1 Hz, send the trigger downstairs.

Simon's previous cable length measurement says it is 505 ns for a signal to travle from Urim to upstairs.

So we should set the latency to be 1010 ns since we are send the signal back down to the V1495.


The latency setting tells the VFAT how many clock cycles to go back in time to look for data in the SRAM. So it depends on MCLK

MCLK is current set to 4.13 MHz = 242 ns = latency = 5.

How long does is take for the V1495 to convert the trigger input on G1 to an output pulse on Port A?

V1495 Internal delay

The scope picture below indicates that when using MCLK = 4.13 MHz the trigger out of the V1495 is about 900 ns after it recieves the G1 input TTL pulse.

2010100110 0342.png

Run 5551

Starting a run using Hall C's CODA on cdaql6.

wrote data to

/local/data1/v1495_l6_5551.dat.0

The rate was about 2.5 Hz according to the CODA GUI

There are still triggers getting dropped by the V1495.

Run 5552

Starting a run using Hall C's CODA on cdaql6.

wrote data to

/local/data1/v1495_l6_5552.dat.0

The rate was about 2.5 Hz according to the CODA GUI

There are still triggers getting dropped by the V1495.


3495 events


Run 5553

Set latency to 0x0a

Starting a run using Hall C's CODA on cdaql6.

wrote data to

/local/data1/v1495_l6_5553.dat.0

data rate has increased, noise in the Hall?

Event Builder crashed.

752 events


Run 5554

Set latency to 0x0a

Data rate is 2-3 Hz

Starting a run using Hall C's CODA on cdaql6.

wrote data to

/local/data1/v1495_l6_5554.dat.0

data rate has increased, noise in the Hall?

Event Builder crashed.

752 events