- genevb's home page
- Posts
- 2024
- 2023
- 2022
- September (1)
- 2021
- 2020
- 2019
- December (1)
- October (4)
- September (2)
- August (6)
- July (1)
- June (2)
- May (4)
- April (2)
- March (3)
- February (3)
- 2018
- 2017
- December (1)
- October (3)
- September (1)
- August (1)
- July (2)
- June (2)
- April (2)
- March (2)
- February (1)
- 2016
- November (2)
- September (1)
- August (2)
- July (1)
- June (2)
- May (2)
- April (1)
- March (5)
- February (2)
- January (1)
- 2015
- December (1)
- October (1)
- September (2)
- June (1)
- May (2)
- April (2)
- March (3)
- February (1)
- January (3)
- 2014
- December (2)
- October (2)
- September (2)
- August (3)
- July (2)
- June (2)
- May (2)
- April (9)
- March (2)
- February (2)
- January (1)
- 2013
- December (5)
- October (3)
- September (3)
- August (1)
- July (1)
- May (4)
- April (4)
- March (7)
- February (1)
- January (2)
- 2012
- December (2)
- November (6)
- October (2)
- September (3)
- August (7)
- July (2)
- June (1)
- May (3)
- April (1)
- March (2)
- February (1)
- 2011
- November (1)
- October (1)
- September (4)
- August (2)
- July (4)
- June (3)
- May (4)
- April (9)
- March (5)
- February (6)
- January (3)
- 2010
- December (3)
- November (6)
- October (3)
- September (1)
- August (5)
- July (1)
- June (4)
- May (1)
- April (2)
- March (2)
- February (4)
- January (2)
- 2009
- November (1)
- October (2)
- September (6)
- August (4)
- July (4)
- June (3)
- May (5)
- April (5)
- March (3)
- February (1)
- 2008
- 2005
- October (1)
- My blog
- Post new blog entry
- All blogs
TPC padAdcSum/counts = 3
The problem was initially noticed as a ratio of the sum (over all time buckets) of pad's ADC values, divided by the DAQ-provided "counts" of non-zero ADCs, gives a ratio of approximately 3. It was discussed on hypernews, but I wanted to make sure it got documented here.
Next curious item....maybe this is just a re-hash of the same problem
Tonko worked on last week (getting clusters at time bucket 185) as
seen from adc values, but I'm not sure so I figured I'd mention it here:
This is a plot of the ADC values summed over all time buckets for any
given pad (this histogram is for all pads):
There's a clear band at about padAdcSum = 3 * counts, where counts is
taken from tpc_t::counts[padrow][pad]. I don't know whether these get
put on tracks. These occurrences seem to appear in clusters (several
pads across, say 10-30 pads, and up to 2 adjacent padrows) in various
sectors (5,8,9,19 from a few events).
Here is a plot of padnumber vs. padrow cutting on this band:
The paired padrows are from the same sector:
If I focus on sector 19, padrow 45, then either the counts or
padAdcSum vs. pads shows this curious cluster of pads with high counts:
Anyone know what's going on? The grouping of several pads, and across
padrows seems interesting....large portions of FEEs?
-Gene
Tonko replies:
There are 5 "warm" FEEs in sectors 5, 6, 8, 9, 19 which seem to have bad grounding (probably due to installation issues such as missing screws or similar). Every few events (1 in 10 or so...) some of them will raise above the zero-suppression cut (which is 3 ADCs) and you will then see this stripe along all (or most) timebins. This is kinda related to TPC hits peak at z = +/- 100cm (time bucket 185). I had to disable a secondary filter in the ALTRO chips which I always used. This filter used to smooth out these small ground shifts which is why I didn't see them during installation. I left those FEEs active because they serve as a "beacon" when I play with the misc filter parameters. Thanks for looking! -- Tonko
- genevb's blog
- Login or register to post comments