Re: summary of 1/29/03-1/30/03 access

Date view Thread view Subject view Author view Attachment view

From: W.J. Llope (llope_at_physics.rice.edu)
Date: Mon Feb 03 2003 - 17:42:45 EST

At 2:44 PM -0600 2/3/03, Frank Geurts wrote:
>>goals:
>> A: specific adc/tdc mapping problem in tofr - must locate & fix!
>
>did something change w/ the last TOFr-TDC unit?

nope. it wasn't touched....

>It appears to be running at 100ps/channel: the strobed data is at
>~470 which is about half of the original values that were at ~960.
>The non-strobed data is consequently 0. A problem in the TDC-start
>could explain only the 0s but not the strobed signals. I traced down
>the previous DMA errors but they were TOFp-ADC related (see below).
>
>> B: scattered problem channels in TOFp that could be fixed given
>>the opportunity.... when this travel was booked there was no intention
>>to address the scattered failed chs in tofp, but (!):
>
>could you send me a list of the locations of the HVC before the
>change (i had a list of some 5 HVCs of which we were not sure which
>TOFp channel they served)

yes i have this info.

>
>item D -- unresolved yet
> Ever since the last access I am seeing DMA errors for TOFp-ADC (see
>below). The logfiles cover the period
>log2: Jan31,08:19 -- Feb1,08:18
>log1: -- Feb2,08:18
>log0: -- Feb3,08:18
>log: -- Feb3,15:11
>
>i don't remember seeing them in earlier logs. Last year we related
>the TOFp DMA errors to Q-suppresion because of the negative
>pedestals. Can you see something like that in the localmon TOFp ADC
>spectra?

i've never seen an adc value less than zero in any localmon data...
remember the "negative pedestals" problems last run were actually
coming from either too much rack heat and/or the fried TOFp
comparators. both of these issues are fixed now i think....

>
>We could consider switching to a slower channel-by-channel readout
>to identify which of the channels causes this problem.

sounds draconian - i.e. how would this affect our dead time?

i'm guessing the interest in running (at least temporarily)
w single channel readout is to locate which ADC (if its
just 1 doing this) that's giving these DMA errors - right?

i have to admit though this problem still seems quote
"rare"/intermittant to me, so i'm not sure if we really
need to track this down - what is the typical rate of
these say per 10k
events according to your logs?

>
>
>[tofp_at_tofp log]% grep DMA det.log*
>det.log:[tof02 14:21:49] (getdata): OPERATOR: getdata.cxx [line
>1199]: DMA read TOFp ADC error
>
>det.log.0:[tof02 02:11:46] (getdata): OPERATOR: getdata.cxx [line
>1199]: DMA read TOFp ADC error
>det.log.0:[tof02 03:19:38] (getdata): OPERATOR: getdata.cxx [line
>1199]: DMA read TOFp ADC error
>
>det.log.2:[tof02 09:23:53] (getdata): OPERATOR: getdata.cxx [line
>1199]: DMA read TOFp ADC error
>det.log.2:[tof02 04:48:07] (getdata): OPERATOR: getdata.cxx [line
>1199]: DMA read TOFp ADC error
>
>
>
>
>cheers,
>-frank 

-- 

  W.J. Llope, Ph.D.                      Res. Assoc. Professor
  T.W. Bonner Nuclear Laboratory         phone:  713-348-4741
  Rice University, MS-315                fax:    713-348-5215
  6100 S. Main St.                  
  Houston, TX 77005-1892            
             e-mail:     llope_at_physics.rice.edu
             WWW home:   http://wjllope.rice.edu/default.html

--
                        
Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.4 : Thu Jul 24 2003 - 00:39:34 EDT