Parameters From Input Files
The CDMSBATS processing and config files have parameters that affect the RTFT processing for the NaI signals in Run 68. Some were originally set sub-optimally so that the timing spectrum was heavily distorted just before the trigger time. The NaI signals are read out with “zip4” in the Run 68 data, so I will go through the modifications we should make to be sure the NaI timing is good for the final analysis.
NaI detector B is in channel A (phonon) and NaI detector C is in channel B (phonon).
Basically the two issues here are the timing window that the RTFT algorithm uses to find the peak and the way the baseline is calculated (the pulse is baseline subtracted before it is normalized). Here are the relevant parameters:
| Input File Parameter | Previous Value | Description |
|---|---|---|
| P_PEAK_WINDOW_MIN | 200e-6 | The distance (in seconds) from the trigger time to place the peak search window starting time. Positive values indicate earlier than start time. |
| P_RTFT_PULLBACK | 150 | The number of samples from the end of the trace to place the peak search window end time. |
| P_BASELINE_MIN | 1 | Low end of the window to use for the baseline calculation in samples. |
| P_BASELINE_MAX | 32 | High end of the window to use for the baseline calculation in samples. |
| P_POSTBASELINE | 32 | Number of samples to include moving backwards in time from the end of the trace to get the post-pulse baseline estimate. |
With these inputs set the way they are there was some impact on the RQs that we might want to use in our analysis because it is often the case that part of the NaI pulse comes during the pre-pulse baseline computation window. In this case the baseline will be computed to be too high, and therefore the pulse is oversubtracted. When that happens the max peak height on the subtracted an normalized pulse doesn't properly measure the peak's departure from the baseline. The timing positions along the pulse when it reaches a fixed-percentage of the total are also thrown off. The time of the peak is not affected.
Below is a table of RQs that may be of use in the NaI coincidence analysis and how they are affected by the processing values above. I use channel “A” as an example, but really any channel that has an NaI plugged in will have the corresponding RQs behave similarly.
| RQ name | Impact of Above Proc. Parameters |
|---|---|
| PAWKr100 | Small impact, as long as the peak is still positive despite the over-subtracted baseline the time value of the highest-point is the same |
| PAWK(r,f)# | For #!=100 this value is affected by the over-subtracted pulses and is generally closer to PAWKr100 than it should be |
| PAbs | This is larger when pulses occur in the region that is between 1 and 32 samples. This is not uncommon for uncorrelated events from NaI detectors and it is not known how common it is for signal events. |
| PAbspost | This is the post-pulse baseline taken from the end of the trace, it's not different with the above parameters from other “more optimal” parameters we would set |
| PAWKmax | Heavily affected by the above parameters, if the pulse is over-subtracted this doesn't measure the pulse amplitude any more, but just the peaks difference from “zero,” which is at an arbitrary location. |
| PAnorm | Not affected by the above parameters but a useful RQ to use for correction (see below) |
We can see the adverse affect of these parameters in the plot below. Over-subtraction is very clear in the region just below the trigger time (x-axis, below 50us). That means that any pulse that comes there will be cut if we put a reasonable sized amplitude cut on the NaI detector. Since we are often selecting for high-energy deposits in the NaI, this is a danger. It is also possible that for the very lowest-energy HV detector events, the trigger time slips so that the NaI pulse is actually in the region below 50us.
| < 40% 50px > |
| Timing/Amplitude Distribution with Original Parameters and Standard RQs |
|---|
 |
| The original parameters for the processing produce a heavy distortion below the trigger time. The axes are (x-axis) PAWKr100, essentially the peak position of the NaI signal and (y-axis) PAWKmax the largest value of the pulse (baseline subtracted and normalized). These are all NaI pulses seen in the DCRC that is called “zip4” in the processing. |
As it turns out, we have enough RQ information to correct this. Since the amplitude are generally normalized like this:
<m>PAWKmax = 1)/PAnorm.</m>
I've done this in the plot below, and the distortion is corrected.
| < 40% 50px > |
| Timing/Amplitude Distribution with Original Parameters and Modified RQs |
|---|
 |
| The distortion can be removed by modifying the amplitude. The axes are (x-axis) PAWKr100, essentially the peak position of the NaI signal and (y-axis) (PAWKmax*PAnorm+(PAbs-PAbspost))/PAnorm, the largest value of the pulse (re-baselined and normalized). These are all NaI pulses seen in the DCRC that is called “zip4” in the processing. |
Based on the fact that this is easily fixed with the existing RQs, I recommend that we keep almost all parameters the same for minimal unknown impacts. I would recommend only changing P_RTFT_PULLBACK to be 0 or some small number. This will make it so that we see the entire timing distribution, not one that cuts off before the end of the pulse (410 us, 512 samples @ 0.8 us per sample). Then in the final analysis we should create an alias for the correct pulseheight given the baseline correction described in the second plot above.
The only downside to this method is that I don't think the non-100% risetime/falltime RQs can be corrected so simply. This is because the RTFT algorithm got a pulse that was over-subtracted and therefore returned the wrong time values. As far as I can see these are not simply related to the correct time values.