LNGS Wiki Pages

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== End of the 7 ms saga? ======

Author: Gio
Date: November 5, 2024

===== Timestamp fix in DAQ software =====

While doing the tests with the pulser (last week) I noticed that we could incur in some truncation issue
when computing the part in second and nanosecond of the timestamp, and later on also in the calculation of the delta-t between events.

The old code (in the Digitizer class of the DAQ software) looked like this:
<code>
double fClockStep_ns = 8.e-9;
double fClockPeriod_ns = fClockStep_ns * (pow(2.,31)-1.);
[...]
double time = startT_double
+ static_cast<double>(fClockPeriod_ns*iteration)
+ static_cast<double>(fTriggerTime*fClockStep_ns);
double time_s;
double time_ns= modf(time,&time_s);
fTimestamp_s = static_cast<unsigned long int>(time_s);
fTimestamp_ns = static_cast<unsigned long int>(time_ns*1.e9+0.5);
</code>
So in practice we were taking the TriggerTimeTag variable from the digitizer, read as an ''unsigned long int'' in the ''fTriggerTime'' variable, casting it into a double, converting it into a timestamp, and then reconverting back the parts in second and in nanosecond of the timestamp, which were written into the output file.

With this software, I noticed that when I injected pairs of events with at 1 us spacing, the reconstructed delta-t suffered by some ~50 ns error which I believe was introduced by the casting, or by the sum of several double variables with too many significant digits.

The new code completely avoids all these type castings and performs all the operations using ''unsigned long int'', thus avoiding any truncation issue:
<code>
unsigned long int fClockStep_ns = 8;
unsigned long int fClockPeriod_ns = 17179869176;
static const unsigned long int fSec = 1000000000;
[...]
unsigned long int time = iteration * fClockPeriod_ns
+ fTriggerTime * fClockStep_ns;
unsigned long int time_s = time / fSec;
unsigned long int time_ns = time % fSec;
fTimestamp_s = time_s + startT_ul;
fTimestamp_ns = time_ns;
</code>
With the new version of the code, the delta-t reconstructed for the pulser data is correct, and also the delta-t distribution for the 219Rn-215Po candidate events matches with the expected half-life of 1.78 ms!

===== Delayed coincidence analysis with new data =====

Starting from October 30, I took data with the GAGG in a 5cm thick Pb shielding, and recording windows of 400ns length (100ns pretrigger, 300ns posttrigger) to search for the 212Bi-212Po delayed coincidences, which have a half-life of ~300 ns. The results are shown below.

==== 219Rn-215Po ====

{{:gagg-nd:screenshot_20241105_172158.png?600|219Rn-215Po delayed coincidence}}

The reconstructed half-life is 1.78+-0.09 ms, perfectly matching the literature value.

==== 223Ra-219Rn ====

{{:gagg-nd:screenshot_20241105_172737.png?600|223Ra-219Rn delayed coincidence}}

The reconstructed half-life is 4.0+-0.4 s, perfectly matching the literature value.

==== 220Rn-216Po ====

{{:gagg-nd:screenshot_20241105_172531.png?600|220Rn-216Po delayed coincidence}}

The reconstructed half-life is 133+-8 ms, matching the literature value at 1.5 sigma.

==== 224Ra-220Rn ====

{{:gagg-nd:screenshot_20241105_172849.png?600|224Ra-220Rn delayed coincidence}}

The reconstructed half-life is 49+-5 s, matching the literature value at just above 1 sigma.

===== Future prospects =====

Out of paranoia and superstition, I fortunately decided to store the TriggerTimeTag variable, in form of an ''unsigned long int'' into the raw data files. This means that in principle we can reconstruct the correct timestamp a posteriori, in Octopus, and hopefully fix the 219Rn-215Po fit also for the long background run of early 2024.

Moreover, if we apply the same correction to the LaBr3 data, we might be able to improve the 215Po half-life measurement even further!
LNGS Wiki Pages

User Tools

Site Tools

Page Tools
