shift summary 7-13-02 0:00-8:00

From: Chris Crawford (chris2@lns.mit.edu)
Date: Sat Jul 13 2002 - 22:59:40 EDT


better late than never-- (network was down this morning)

00:00-08:00 Kevin McIlhany, Chris Crawford.

Runs: (see organization.txt)
489-505

Some headway was made into the retimingOR "mystery". Apparently, the
"electronics.map" file had a double entry for sector=1 detector1,2=0.
This is exactly where the retimingOR rests. The end result is that the
next
detector in the file had the same listing which resulted in CODA
interpreting the signals from the next detector AS IF it was the
retimingOR,
yet in reality it was the right cerenkov tubes. WE found this out the
hard
way by doing several things:

1) We along with many others, physically traced the path of the
retimingOR
signal from it source, the 4564 module to its end, the "right" TDC
crate.
2) We hoped to identify in the analysis the retimingOR signal by
temporarily
adding a 5ns delay to the signal. (Runs 474x,475x,476x,477x,478x,479x
and 491)
The "x" next to the run number refers to the fact that these runs were
OVER-WRITING prvious runs due to CODA being a bad monkey.
3) For comparison, the runs just prior to adding the delay are:
481-488.
4) Run 492 thru 499 have the delay removed so that the retimingOR
signal
was back in its original state.
5) Runs 500 and 501 had the retimingOR completely removed between the
NIM
signal translator and the TDC.
6) Runs 502 and onward were all back to normal until Tancredi showed
up.

Conclusions: The software showed NO CHANGE due to anything we did last
night.
As a result, we began investigating the decoding process and discovered
(due
to Chris) the double entry mentioned above. Chris has now commented out
the
offending line in the "electronics.map" file and we are awaiting more
data
taking to verify that we are finally reading the actual retimingOR
signal.



This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:28 EST