- we have few cables from the west carriage to the counting house
    - PMT - 310 ns
    - on-board preamp - 340 ns
- optical fibers
    - Laser to junction box - 242 ns
    - Junction box to splitter - 72.4 ns
    - Splitter to detector         - 29.9 ns
Detector delays
    - optical delay                    - 2ns
    - PMT Transit time           - ~15 ns
    - Cable to FEM                   - 6.1 ns

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

/export/data1/dcm_data/cw/l1delay_scan_00995-01008.evt   (14 files, initial GTM delay 16).

We have changed Laser amplitude (decreased) and repeated few more runs to see if TAC will be affected

/export/data1/dcm_data/cw/l1delay_scan_01009-01013.evt   (5 files, initial GTM delay 20).

/export/data1/dcm_data/cw/l1delay_scan_01021-01023.evt   (5 files, initial GTM delay 20).

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.dat
/export/software/oncs/R2.5/online_configuration/rc/hw/pbsc_w.pcf

/export/software/oncs/R-pro/online_configuration/GTM/GTM.EMClaser.gtm
/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 :
  Picture above is for RMS in presample High gain. Simiilar picture for Low Gain and TAC was showing only one badly behaving ASIC. We will try to replace DataFormatter.
W0, SM14           - DF #66 was substituted by DF#105,  O'K
W0, SM0              -ASIC4 (#141) , base #28, ch 1 was   substituted ASIC# 84.

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

CRATE 100 ASIC 1 TAC (RAW) TAC 1 UPDATE IMPOSSIBLE - TOO BAD DATA
MEASUREMENTS ACCEPTED: LEVELS 4 CONNECTED CHANNELS 0
 IRef 56/54 VRef 44/44
CRATE 75 ASIC 4 TAC (RAW) TAC 0 UPDATE IMPOSSIBLE - TOO BAD DATA
MEASUREMENTS ACCEPTED: LEVELS 3 CONNECTED CHANNELS 0
IRef 50/48 VRef 61/61

CRATE 75 ASIC 4 TAC (RAW) TAC 0 UPDATE IMPOSSIBLE - TOO BAD DATA
MEASUREMENTS ACCEPTED: LEVELS 3 CONNECTED CHANNELS 0
 IRef 48/48 VRef 61/59

W1/SM10/A2
W1/SM13/A1
W1/SM13/A4
W1/SM5/A4
W1/SM7/A2

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
  Conclusions: Current GTM delay (28) is OK for every crate except Monitoring one.  We will work on monitoring crate when new AL code will be tried.

- 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.