![]() |
|
To update LOGBOOK - open this
page in composer i.e.: File->Open Page->/home/phnxemc/EmcDoc/Logbook.html
Always type your name and date.
Delay between leading edge of the test pulse triigger to Preamp boad
and signal from preamp seen in the counting house is ~770 ns
Forced accept usually comes out of GTM 430 ns later then the signal
from on-board preamp reaches counting house
Muon trigger is seen in the counting house 260 ns later then
on-board preamp signal when both are due to Laser pulses.
The following runs were taken with a lot of light to verify LVL1/GTM
delays
We have changed Laser amplitude (decreased) and repeated few more runs to see if TAC will be affected
Most likely explanation to our current problems with TAC - it was CFD
mode selected via serial string with parameters controlling it set to something
out of proportions. Needs further testing.
/export/software/oncs/R2.5/online_configuration/Arcnet/gdb.datNew GTM files which trigger events of a single kind only are now available
/export/software/oncs/R2.5/online_configuration/rc/hw/pbsc_w.pcf
/export/software/oncs/R-pro/online_configuration/GTM/GTM.EMClaser.gtmMatching between two files is now done using names like FEM.EMC.W0.SM00
/export/software/oncs/R-pro/online_configuration/GTM/GTM.EMCpedestal.gtm
/export/software/oncs/R-pro/online_configuration/GTM/GTM.EMCtestpulse.gtm
New event file: /export/data1/dcm_data/emc/emc_run_01053.evt
-
first test with timing discriminators in LE mode for ASIC_0 in both frames.
Just pedestals
To CW: attempt to change modebitfile without reloading
everything failed - Segmentation - strange thing - some comments were printed
in DCM window?
01/05/00
/export/data1/dcm_data/emc/emc_run_01079.evt
-
pedestal run. HV ON from yesterday. RC failure when attempted to change
mode bit file without reloading everything.
/export/data1/dcm_data/emc/emc_run_01081.evt
-
laser run (amplitudes low, same settings as at the end of yesterday)
/export/data1/dcm_data/emc/emc_run_01092.evt
-
laser run (lot of new messages in DCM window) HV on the detector was off
- only Laser signals on PHD are seen
/export/data1/dcm_data/emc/emc_run_01093.evt
- new laser run, HV everywhere = 1300V.
/export/data1/dcm_data/emc/emc_run_01094.evt - new laser
run usen "NO FORCED ACCEPT" mode. GTM delay increased to 25
01/06/00
To make things happen without GLVL1 we pulled the ForcedAccept
off and simply sent the trigger into GTM through the front panel (TTL,
100 ns wide). One thing which was important is to have TimingSystem interface
open and Local Forced Accept and LVL1 Block State toggled to "YELLOW".
/export/data1/dcm_data/emc/emc_run_01104.evt
-
laserNFA run. HV ON at 1300V. GTM delay of 22
/export/data1/dcm_data/emc/emc_run_01105.evt
-
laserNFA run. HV ON at 1300V. GTM delay of 25
/export/data1/dcm_data/emc/emc_run_01109.evt
- laserNFA run. HV from E16.Y1 defaults, 10k events. This is the
first serious laser run, it is taken with trigger going through the front
panel . Unfortunately it has only ASIC0 in both crates in LED state, the
rest are in CFD with wrong settings.
We have changed settings in ASIC 1 / 2 / 3 /4
to CFD with 0/13, 10/12 and 12/10 7/7 settings to see how it will
affect timing measurements.
/export/data1/dcm_data/emc/emc_run_01114.evt
- short file to see the outcome. 0/13 and 7/7 both work. The decision for
now - keep Crate1 in LED mode, change Crate2 to CFD mode with parameters
set to 13/0
/export/data1/dcm_data/emc/emc_run_01115.evt
- 2000 laserNFA events under the same conditions
/export/data1/dcm_data/emc/emc_run_01116.evt
- 3000 events, test pulse, same conditions
/export/data1/dcm_data/emc/emc_run_01117.evt
- 2500 laserNFA events under the same conditions. Most
likely these are events recorded with test-pulse mode bit file.
/export/data1/dcm_data/emc/emc_run_01118.evt
- one more file with laser events. Crate1-CFD (0/13), Crate2 - LED.
/export/data1/dcm_data/emc/emc_run_01121.evt
- one more file with laser events. Crate1-CFD (0/13), Crate2 - LED. Trigger
to laser is delayed for 8 ns
/export/data1/dcm_data/emc/emc_run_01122.evt
- one more file with laser events. Crate1-CFD (0/13), Crate2 - LED. Trigger
to laser is delayed for 16 ns
/export/data1/dcm_data/emc/emc_run_01123.evt
-
one more file under control of testpulseNFA with testpulse trigger
disconnected from PPG - pedestals everywhere. Crate1-CFD (0/13), Crate2
- LED.
The picture below is for the variations in TAC
values in the same channel measured with different delays. While run-to-run
differences are OK (~25 ps per count) the behavior within individual runs
looks a bit strange. Drift is obvious, the question - where it comes from.
/export/data1/dcm_data/emc/emc_run_01265.evt
- laser, HV-on (16 GeV). GTM delay was set to 25. All TAC values
became negative after pedestal subtraction ????? but .... laser was not
actually on. Here is the question - what changed the pedestals ????????????????????
If this is just due to the leackage current in AMU - pedestals need to
be rewritten.
/export/data1/dcm_data/emc/emc_run_01266.evt
- laser, HV-on` (16 GeV) GTM delay is at 25
The two pictures above are High vs Low Gain values in one channel (left)
and the distribution of the intercepts measured for all channels with
reasonable amplitudes in 10 FEM crates(right). Data in these pictures are
very preliminary. The interesting features - relatively large jitter in
laser amplitudes (100-150 counts on a low gain scale) and the presence
of a few events in the beginnning of the run with very low amplitudes (checked
- they are really the first in the run). Another feature - lines do not
point to zero. In general - the intercept is positive what is a bit unexpected
from what we already know about our FEM's.
1. Fiber from SM6 to SM0 - glink locks -> SM0 OK, problems with communication
line
to SM1 - failed
SM1 - problems
Fiber from SM4 to SM10 - failed
to SM3 - failed
to SM9 - failed
Conclusions: Crates 0010(SM0), 0014(SM1), 201(SM3), 202(SM9), 0015(SM10)
need further investigation.
2. We also cured the problems with SM5. We first replaced both HM and
DF, then returned HM card back to its original position. This was sufficient.
Conclusion DF board #17 needs repair.
/export/data1/dcm_data/emc/mult2_3.evt - Vref 57 everywhere, CFD threshold 60. Negative but understandable result - we probably have ADC rump in TAC too fast - count reaches 4095 before the threshold is reached.
/export/data1/dcm_data/emc/mult2_4.evt
- CFD threshold 50, H/L - 60/55, TAC - 53/57
/export/data1/dcm_data/emc/mult2_5.evt
- CFD threshold 50, H/L - 63/55, TAC - 53/53 - very few of the TAC
channels are in the overflow now
/export/data1/dcm_data/emc/mult2_8.evt
- same serials, all troublesome cards replaced
![]() |
The processing took 18 mins for 10k events from a single sector. There
are couple of channels which are clearly metastable, nothing really bad
is seen in the data. All pedestals are pretty stable (see above), TAC included.
I am back down to 60 as VRef default in amplitude channel.
After 16 attempts for improve References we got follow:
CRATE 87 ASIC 3 HG-POST (RAW) CONTROLLED UPDATE IMPOSSIBLE - TOO BAD
DATA
MEASUREMENTS ACCEPTED: i4 0 i25 8
IRef 55/55 VRef 61/61
CRATE 87 ASIC 3 LG-POST (RAW) CONTROLLED UPDATE IMPOSSIBLE - TOO BAD
DATA
MEASUREMENTS ACCEPTED: i4 0 i25 8
IRef 55/55 VRef 61/61
CRATE 88 ASIC 3 HG-POST (RAW) CONTROLLED UPDATE IMPOSSIBLE - TOO BAD
DATA
MEASUREMENTS ACCEPTED: i4 0 i25 0
IRef 48/48 VRef 44/44
CRATE 88 ASIC 3 LG-POST (RAW) CONTROLLED UPDATE IMPOSSIBLE - TOO BAD
DATA
MEASUREMENTS ACCEPTED: i4 0 i25 0
IRef 48/48 VRef 44/44
CRATE 88 ASIC 3 TAC (RAW) TAC 0 UPDATE IMPOSSIBLE - TOO BAD DATA
MEASUREMENTS ACCEPTED: LEVELS 0 CONNECTED CHANNELS 0
IRef 48/48 VRef 59/57
CRATE 88 ASIC 3 TAC (RAW) TAC 1 UPDATE IMPOSSIBLE - TOO BAD DATA
MEASUREMENTS ACCEPTED: LEVELS 0 CONNECTED CHANNELS 0
IRef 48/48 VRef 59/57
4/9/00 E.Kistenev
After a lot of tuning and replaces - all our crates almost behaved.
Suddenly
Locatiion is w0 /SM13(crate 81) ?????????????????????????????????? Reloading
serial data would not help. Another continuosly present "minor"
problem just got a bit worth:
FEM 30(23) WRONG_AMU CELL ADDRESSES(36-36-35)
It was creating error conditions when pre-sample would hit cell 34,
it now expanded to cell 32. I decided nevertheless that it is time to compute
pedestals using earlier recordaed long file (w_b_ped_HVON.evt). l
4.25.00 S.Chernichenko/A.Durum
Replacement history.
1. Data were taken using predefined settings. The following FEM's were
found to have noisy channels :
![]() |
4/26/00 E.Kistenev/A.Durum
Replacement history Table
We had almost a mystery today.
Date | Sector | SM(FEM) | HG | LG | TAC | DIAGNOSIS |
4/26/00 | W0 | SM5(17) | noisy single channel in ASIC2 | replace ASIC2 () | ||
4/26/00 | W1 | SM4(89) | 2 noisy channels out of every 4 | ASIC 5, noisy disconnected channels | ASIC 5, everything noisy | replace ASIC5 (we already replaced
Heap Man. and DF earlier) |
4/26/00 | W1 | SM11() | ASIC5, noisy first AMU/ADC chip | disconnect all three cables and try again
(ASIC board was replaced earlier) |
||
4/26/00 | W1 | SM14() | ASIC 3, all channels noisy | wait for the outcome of a test on W1/SM11 | ||
4/26/00 | W0 | SM2 | Suddenly became similar to W1/SM4 (2 out of 4) | Noise x2 above normal in all channels | Fiber into DCM | |
W0 | SM8 | ASIC 1 - noise x2 above normal | ||||
W0 | SM14 | ASIC5 - noise x2 above | ||||
W1 | SM3 | noise x1.5 in all channels | All ASICs except 0 - x2 in the noise | |||
W1 | SM4 | Stiill old story (2out of 4) | Fiber into DCM | |||
W1 | SM9 | All ASIC's - x2 -n the noise | ||||
W1 | SM13 | ASIC3 - noise x 2 above normal | ASIC3 - noise in disconnected channels seems too high | ASIC3 - x2 in the noise | ||
W1 | SM14 | ASIC3 - noise x5 above normal | ASIC3 - same story - noise | ASIC3 - x10 in the noise | Replaced ASIC3 331->227 | |
4/26/00 | W0 | SM1 | ASIC0, input0,cable30, tower121 -
noise x50 |
|||
W1 | SM10 | ASIC0 - noise x 2 | ASIC2 - all channels REJECT !?? | |||
5/07/00 E.Kistenev/A.Durum
Fine tuning of FEM's before dry run
Iteration 1
Among other problems - some channels stop behaving from time to time
(noise suddenly gets out of proportions). Comparison to data taken
more then a month ago (HV probably different from what is loaded now) shows
that the situation deteriorated, we have more noise today.
wb_ped_HVON.evt - 10k events with HV on (16 GeV range?)
wb_ped_HVOFF.evt - 10k events with HV off (save in file /home/phnxemc/workarea/PbSc/wb__ped10000.dat)
22.40 by A.Durum
Hv is ON
Update pedestalls. Save in file wb_ped_HVOFF.evt (?)
23.25 Laser data with various delays: w_b_las24.evt (24-32 clocks),
there are 200 events in each file.
0.05 Laser data with delay 28 with various intensity: w_b_las28_var099.evt
(099 - how much % of max light intensity) 099-080-060-040-020-015-010-005-003-0015-00000.
99% is corresponded to 95mv signal from PMT base.
80% - 80mv
60% - 60mv
40% - 40mv
20% - 20mv
15% - ~17mv
10% - ~11mv
5% - ~5mv
3% - ~3mv
1.5%- ~1-2mv
0.0000%-~ ???mv (easy connecting fibres) -
very linearity dependence...Shean is good man!
0.55 Laser data with delay 28, intensity~50%, 500 events, various delay
on Qswitch:
w_b_las28_varQswitch+0ns.evt - normal position,
+4, +8, +10, +16, +24, +32,+40,+48 - how much ns added to delay
Qswitch.
1.45 Disconnect adding delay cables.
1.50 After ~3 hour when HV ON, began collected pedestalls. File
wb_ped_HVON_second.evt - 10k events with HV on.
3.30 Today all works finished, HV, LV and I is OFF.
Good Luck!
5/9/00 E.Kistenev
- Pedestal files were updated (A.Durum)
from wb_ped_HVOFF.evt. Subtracting these from the data in the next HVON
pedestal files shows that pedestals are correct and subtraction works.
Noise is still there but largely improved compared to the one observed
in the first file.
![]() |
![]() |
![]() |
- Finding correct GTM delay
![]() |
![]() |
![]() |
![]() |
- High/Low ratios
![]() |
![]() |
![]() |
![]() |
![]() |
Conclusions: Some work is still needed - primarily to fix criteria for the data being acceptable (thresholds used in EmcalFEE to qualify the data)
- Timing Calibration
![]() |
![]() |
![]() |
![]() |
05/16/00 Durum & Chernichenko.
We tried to improve threshold CFD (ZCC1). First picture is corresponded
threshold=10, second 11, third 12, forth 13 with constant "amplifing" =
7.
The maximum of threshold is 10.
In the next step we tried to improve slewing of dependens
TOF from Amplitude using variously ZCC2 from 0 by 15 (maximum value).
We got better picter with ZCC2=15.
Conclusions: In TAC we established ZCC1=10, ZCC2=15.
5/19/00
Table below are the data from W0/W1 references grouped as off/on board
sector w0 then sector W1. What is totally puzzling - timing difference
- was understood when Sean said that the third integrating board is a bit
different from the first two.
Still - we are facing major problem - clock for the monitoring board
must be delayed (one clock tick) and the best solution is probably to add
20 m of optical fiber.
Pictures below:
FA delayed with respect to past for 10 clocks
All cell positions are at 3/4
Left: Integrating boards 0/2, Right - integrating board 4 (red - two
channels wich do have caps, all other channels do not have caps)
![]() |
![]() |
![]() |
![]() |
The next figures are for the test pulse. Left to right, top to bottom
are GTM delays 17, 18, 19, 20.
![]() |
![]() |
![]() |
![]() |
When initial testing was over - we modified GTM programs to synchronize
our ForcedAccept with Beam-Beam LLV1. Final setting - we need 16 clock
ticks delay in GTM to get events out of FEM when triggered by GLV1.