00:00-08:00 Kevin McIlhany, Chris Crawford.
Runs: (see organization.txt)
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
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