Pedestal subtraction "mistakes" for all Detectors that employ fADC250 #751
Comments
|
It would be very useful to know how often this happens for each detector. |
|
rate of QF occurance as a function of readout channel number for various detectors using fADC250. this is for a GlueX production run at 300nA on Diamond radiator. (run 121204) The vertical axis is Number of QF occurences for this channel
|
|
the following is the same but for run 121153 with 900nA beam current and specialized trigger thresholds to handle Note: The physics trigger involves FCAL-BCAL comobination so the "rates" in the FCAL and BCAL have to be taken
|
|
Hi Beni,
is the rate of occurrence the number of mistakes/triggers or
mistakes/number of hits in that detector element ?
I would expect it to be mistakes/triggers which should mostly explain the
shape of the distributions, but for the SC I am surprised that the rate is
double on one side with respect to the other, even though it's not exactly
parallel to the beam that seems large.
Naomi.
…On Mon, Sep 25, 2023 at 9:43 PM zihlmann ***@***.***> wrote:
the following is the same but for run 121153 with 900nA beam current and
specialized trigger thresholds to handle
the rates. Note that some of the detectors were turned off during this run
test.
[image: qf_pedestal_fail_run121153]
<https://user-images.githubusercontent.com/13365259/270511588-2ae8164b-a06f-4030-ba8a-6cad5b022a72.gif>
—
Reply to this email directly, view it on GitHub
<#751 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADXOCVXXYOH7HPVSOJ6HKWDX4IXMHANCNFSM6AAAAAA5F6XIHE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
the normalizing number is the "trigger number"
the nominator is the number of hits found. This number can be bigger
than 1 for a trigger since
there can be more than one signal in the same counter for a given
trigger. I did not want to count
only once since I think what matters is how often a pedestal has to be
"fixed".
regarding the SC. The rate is completely dominated by the tip. Any small
changes in the location of
the tip will have a huge impact on the rate. The "failing" of the
pedestal determination is heavily
rate dependent because that is what defines the probability for a "tail"
of a signal at the start of
the readout window.
…On 9/26/23 09:28, nsjarvis wrote:
Hi Beni,
is the rate of occurrence the number of mistakes/triggers or
mistakes/number of hits in that detector element ?
I would expect it to be mistakes/triggers which should mostly explain the
shape of the distributions, but for the SC I am surprised that the
rate is
double on one side with respect to the other, even though it's not
exactly
parallel to the beam that seems large.
Naomi.
On Mon, Sep 25, 2023 at 9:43 PM zihlmann ***@***.***> wrote:
> the following is the same but for run 121153 with 900nA beam current
and
> specialized trigger thresholds to handle
> the rates. Note that some of the detectors were turned off during
this run
> test.
>
> [image: qf_pedestal_fail_run121153]
>
<https://user-images.githubusercontent.com/13365259/270511588-2ae8164b-a06f-4030-ba8a-6cad5b022a72.gif>
>
> —
> Reply to this email directly, view it on GitHub
>
<#751 (comment)>,
> or unsubscribe
>
<https://github.com/notifications/unsubscribe-auth/ADXOCVXXYOH7HPVSOJ6HKWDX4IXMHANCNFSM6AAAAAA5F6XIHE>
> .
> You are receiving this because you are subscribed to this
thread.Message
> ID: ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_halld-5Frecon_issues_751-23issuecomment-2D1735544085&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=Hy7ijcc6pcMoP-QxZxtQH4-vodW_VGkrA9xiBc7InXk&m=Juhtmh-tk4LT0FatnLe1DdwQZSRS3PoPxLY2z12bh7R-Y0eOwR1aVcd00C9PpING&s=1DvjhHCzg0bhurOyVTOqhSJHI2HgUW18ldf5b-nYXpc&e=>,
or unsubscribe
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADF7AC3PPDMXZLO2GRQBIITX4LJ6BANCNFSM6AAAAAA5F6XIHE&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=Hy7ijcc6pcMoP-QxZxtQH4-vodW_VGkrA9xiBc7InXk&m=Juhtmh-tk4LT0FatnLe1DdwQZSRS3PoPxLY2z12bh7R-Y0eOwR1aVcd00C9PpING&s=Si1mJbNYvw7A1oThWisLXIP6Ecc4sE3lK1iHKGn3u2Q&e=>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--------------SikUE2TcKDQzMro6AS09ktbn
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
the normalizing number is the "trigger number"<br>
the nominator is the number of hits found. This number can be bigger
than 1 for a trigger since <br>
there can be more than one signal in the same counter for a given
trigger. I did not want to count<br>
only once since I think what matters is how often a pedestal has to
be "fixed".<br>
<br>
regarding the SC. The rate is completely dominated by the tip. Any
small changes in the location of<br>
the tip will have a huge impact on the rate. The "failing" of the
pedestal determination is heavily<br>
rate dependent because that is what defines the probability for a
"tail" of a signal at the start of<br>
the readout window.<br>
<br>
<div class="moz-cite-prefix">On 9/26/23 09:28, nsjarvis wrote:<br>
</div>
<blockquote type="cite" ***@***.***">
Hi Beni,
<br>
<br>
is the rate of occurrence the number of mistakes/triggers or
<br>
mistakes/number of hits in that detector element ?
<br>
<br>
I would expect it to be mistakes/triggers which should mostly
explain the
<br>
shape of the distributions, but for the SC I am surprised that the
rate is
<br>
double on one side with respect to the other, even though it's not
exactly
<br>
parallel to the beam that seems large.
<br>
<br>
Naomi.
<br>
<br>
On Mon, Sep 25, 2023 at 9:43 PM zihlmann ***@***.***> wrote:
<br>
<br>
> the following is the same but for run 121153 with 900nA beam
current and
<br>
> specialized trigger thresholds to handle
<br>
> the rates. Note that some of the detectors were turned off
during this run
<br>
> test.
<br>
>
<br>
> [image: qf_pedestal_fail_run121153]
<br>
>
<a class="moz-txt-link-rfc2396E" href="https://user-images.githubusercontent.com/13365259/270511588-2ae8164b-a06f-4030-ba8a-6cad5b022a72.gif"><https://user-images.githubusercontent.com/13365259/270511588-2ae8164b-a06f-4030-ba8a-6cad5b022a72.gif></a><br>
>
<br>
> —
<br>
> Reply to this email directly, view it on GitHub
<br>
>
<a class="moz-txt-link-rfc2396E" href="#751 (comment)"><https://github.com/JeffersonLab/halld_recon/issues/751#issuecomment-1734701224></a>,<br>
> or unsubscribe
<br>
>
<a class="moz-txt-link-rfc2396E" href="https://github.com/notifications/unsubscribe-auth/ADXOCVXXYOH7HPVSOJ6HKWDX4IXMHANCNFSM6AAAAAA5F6XIHE"><https://github.com/notifications/unsubscribe-auth/ADXOCVXXYOH7HPVSOJ6HKWDX4IXMHANCNFSM6AAAAAA5F6XIHE></a><br>
> .
<br>
> You are receiving this because you are subscribed to this
thread.Message
<br>
> ID: ***@***.***>
<br>
>
<br>
<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br>
Reply to this email directly, <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_halld-5Frecon_issues_751-23issuecomment-2D1735544085&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=Hy7ijcc6pcMoP-QxZxtQH4-vodW_VGkrA9xiBc7InXk&m=Juhtmh-tk4LT0FatnLe1DdwQZSRS3PoPxLY2z12bh7R-Y0eOwR1aVcd00C9PpING&s=1DvjhHCzg0bhurOyVTOqhSJHI2HgUW18ldf5b-nYXpc&e=" moz-do-not-send="true">view it on GitHub</a>, or <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADF7AC3PPDMXZLO2GRQBIITX4LJ6BANCNFSM6AAAAAA5F6XIHE&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=Hy7ijcc6pcMoP-QxZxtQH4-vodW_VGkrA9xiBc7InXk&m=Juhtmh-tk4LT0FatnLe1DdwQZSRS3PoPxLY2z12bh7R-Y0eOwR1aVcd00C9PpING&s=Si1mJbNYvw7A1oThWisLXIP6Ecc4sE3lK1iHKGn3u2Q&e=" moz-do-not-send="true">unsubscribe</a>.<br>
You are receiving this because you authored the thread.<img src="https://github.com/notifications/beacon/ADF7ACZHFRG2HX2TSJYKURDX4LJ6BA5CNFSM6AAAAAA5F6XIHGWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTHOJGRK.gif" alt="" moz-do-not-send="true" width="1" height="1"><span style="color: transparent; font-size: 0; display: none;
visibility: hidden; overflow: hidden; opacity: 0; width: 0;
height: 0; max-width: 0; max-height: 0; mso-hide: all">Message
ID: <span><JeffersonLab/halld_recon/issues/751/1735544085</span><span>@</span><span>github</span><span>.</span><span>com></span></span></p>
<script type="application/ld+json">[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "#751 (comment)",
"url": "#751 (comment)",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
</blockquote>
<br>
</body>
</html>
--------------SikUE2TcKDQzMro6AS09ktbn--
|
|
The occupancy in 2023's SC monitoring plots is only ~ 30% higher in the middle-number counters (15 ish), but I suppose the algorithm failure rate is some power of this. |
|
for completeness these are the pedestals for the high intensity run 121153 where a pedestal value is reported.
|
![https://user-images.githubusercontent.com/13365259/270511588-2ae8164b-a06f-4030-ba8a-6cad5b022a72.gif"><https://user-images.githubusercontent.com/13365259/270511588-2ae8164b-a06f-4030-ba8a-6cad5b022a72.gif></a><br](https://user-images.githubusercontent.com/13365259/270511588-2ae8164b-a06f-4030-ba8a-6cad5b022a72.gif"><https://user-images.githubusercontent.com/13365259/270511588-2ae8164b-a06f-4030-ba8a-6cad5b022a72.gif></a><br){kind=link}
|
Please take a look and consider updating the CCDB with pedestal values that make sens to be used as alternative to when the pedestal data is not available from the raw data. |
|
We should resolve this for all detectors before the CPP data start production - I suggest we review the situation and make some decisions in the next C&P meeting. @nsjarvis pointed out this high priority action item - https://halldweb.jlab.org/wiki-private/index.php/December_13,_2023,_Calibration_%26_Production#Old_Action_Items |
|
Verified that the TAGM and TAGH default pedestals were all set to 250 in ccdb, whereas should be 100. Changed to 100 for all runs 10000-inf , var=mc and var=default, for both microscope and hodoscope. Updates verified. |
There are several issues regarding the handling of the pedestals in the detectors that
using fADC250. The algorithm on the FPGA is providing a value for the pedestal, however
if the algorithm fails to determine a proper value a quality factor QF is non zero and
in digi hits is reported as QF & 0x40. There are other QF bits set for other problems
the algorithm may have had but in case of a failed pedestal determination the 7th bit
is set.
The base approach when constructing detector hits in a DANA factory is to use the pedestal
provided by the FPGA algorithm but in the case the pedestal determination failed an average
pedestal from CCDB pedestal table is to be used.
So in the hit factory code an initial value for the pedestal is set using CCDB data
// For now, only keep events with a correct pedestal
double pedestal = a_pedestals[digihit->sector-1];
And later on the pedestal from the FPGA is used if the quality factor QF is ok
// digihit->pedestal is the sum of "nsamples_pedestal" samples
// Calculate the average pedestal per sample
if( (digihit->pedestal>0) && locTTabUtilities->CheckFADC250_PedestalOK(digihit->QF) ) {
pedestal = (double)digihit->pedestal/nsamples_pedestal;
}
the above code snipets are from libraries/START_COUNTER/DSCHit_factory.cc but other detectors
have very similar codes in their factories with the same result.
It turns out that there are ISSUES with this approach for various reasons:
a) the ccdb tables are always set to zero: Start Counter
This means no pedestal subtraction if QF == 0x40!
b) the ccdb tables are always set to a wrong value (250 instead of 100): Tagger hodoscope and microscope
this means the wrong pedestal of 250 is subtracted if QF == 0x40!
for the tagger hodoscope this is even more problematic since the base line shifts significantly with
increasing beam current to lower values.
c) the ccdb table is NOT used at all since in the case of a failed pedestal the hit is ignored: BCAL
what is meant by this statement is that if QF == 0x40 the factory discards the hit.
d) the ccdb table is not updated for all run periods and just fixed to 100: TOF
one can verify these problems in the factories that create the detector hits:
DBCALHit_factory.cc
DSCHit_factory.cc
DTAGHHit_factory_Calib.cc
DTAGMHit_factory_Calib.cc
DTOFHit_factory.cc
and to check what is in CCDB regarding pedestal XXXXXXX==runnumber:
ccdb dump PHOTON_BEAM/microscope/fadc_pedestals:XXXXXX all 250
ccdb dump PHOTON_BEAM/hodoscope/fadc_pedestals:XXXXXX all 250
ccdb dump StartCounter/pedestals:XXXXXX all zero
ccdb dump BCAL/ADC_pedestals:XXXXXX all zero
ccdb dump TOF2/pedestals:XXXXXX all 100 for run > 80k
ccdb dump FCAL/pedestals:XXXXXX looks OK
This is a subjective order of severity:
a) all BCAL hits where the pedestal determination failed are discarded
a) all tagger hits where the pedestal failed 250 is subtracted from the ADC values
b) all Start Counter hits where the pedestal failed zero is subtracted (no pedestal subtraction)
c) all TOF hits where the pedestal failed the pedestal subtraction is fixed to 100 for run periods 80k and onward
The text was updated successfully, but these errors were encountered: