Identifying Events with Ringing Tap Signals

Introduction

In an earlier memo, "HRC tap corrections", and more detailed SPIE paper I described a method to remove some of the distortion in calculated HRC event positions by applying corrections to the crossed-grid charge detector signals. The method involved identifying which events were affected on each axis on an event-by-event basis and for these events adjusting one of the tap amplitudes according to the other two tap values on the axis using an empirically derived relationship.

A major issue in performing the correction is identifying the events to which the correction should be applied given the available telemetry. From our understanding of the fundamental problem with the HRC hardware, we know that the events that are affected by the ringing problem occur when an even number of taps have signals above a threshold level and the event amplitude is large enough for the hardware to select the lowest gain setting on the range switching amplifiers. The amplifier scale selected by the hardware for event processing appears in telemetry for each event (it is, however, occasionally reported incorrectly). Unfortunately, we have no direct measure of the number of taps along an axis that have a signal above threshold. The earlier memo suggested using a simple ratio comparison between the two tap signals; however, the data to support this criterion was limited.

In the SPIE paper, I suggested that we could obtain a nearly unambiguous indicator of which events required the correction by lowering the event-width threshold from 3 to 2. The event-width is determined by the HRC coarse position logic from the highest and lowest number taps above the trigger threshold. If the width of the event along a detector axis in coarse position units exceeds the commanded event-width threshold a bit in the event telemetry is set. At a threshold value of 3, very few (~0.1%) events have the width exceeded bits set, indicating that nearly all events have a width of 3 or less. More critically, those events with a width on an axis of more than 3 appear to be attributed to non-X-ray events and have other signatures that can be used to reject them.

Effective 2000:279:12:57 the commanded default event-width threshold was lowered to 2. This provides us with an improved means to identify the events which require a tap signal correction. It also provides us with the data we need to improve our means of determining which events should be corrected when for the times prior to the lowering of the event-width threshold.

Which Event to Correct?

The events processed on the lowest gain setting (AMP_SF=3) and which have an even number of tap exceeding a threshold are subject to the ringing problem. Since very few events have a width greater than 3 coarse positions, once the commanded event-width threshold is set to 2 we can assume that if the width exceeded bit is set, the width is 3. The total amplitude of the events when the hardware selects the lowest gain setting is such that the event width is always greater than 1. Thus when AMP_SF=3 the state of the width-exceeded bit for a given axis tells us whether we should apply a ringing correction (if not set apply one, if set do not apply one). We can use this indicator in an examination of tap data to define better criteria for applying the correction when the commanded event-width threshold is set to something other than 2. Figure 1 shows scatter plots of events from an HRC-I data set where we have used the width-exceeded bits to distinguish events that do not require a ringing correction (Wide Events) from those that do (Non-Wide Events). The events were selected to have AMP_SF=3, be on the negative side of the coarse position, and be well behaved in some other simple respects (center tap of the triplet is largest, sum of tap signals on U or V is non zero,...).

HRC-I U-axis Wide vs
Non-Wide Events HRC-I V-axis Wide vs
Non-Wide Events

Figure 1: a) Comparison of AU1 to AU2 on HRC-I for Wide and for Non-Wide events. Non-Wide events should have a tap ringing correction applied before event positions are calculated. The dashed line is the current discrimination criterion; the solid line is a suggested improvement. b) Comparison of AV1 to AV2 on HRC-I for Wide and for Non-Wide events. Non-Wide events should have a tap ringing correction applied before event positions are calculated. The dashed line is the current discrimination criterion; the solid line is one suggested improvement.

The first thing to notice is that a much larger fraction of the events on the U-axis are wide than on the V-axis. The wide an non-wide events segregate, as is expected, but the boundary is fuzzy. There are two lines over-plotted in the plots in the figure. The dashed line in each pane is the currently defined discriminator of when the tap ringing correction is to be applied; clearly this is a poor choice. The solid line is an improved criterion for discrimination; however, on the HRC-I V-axis we might just as well apply the correction to any event on the negative side of the coarse position when AMP_SF=3. Figure 2 Is a similar plot to figure 1 but for the HRC-S. As with the HRC-I V-axis, the ringing correction could be simply applied to any event on the negative side of the coarse position when AMP_SF=3.

HRC-S U-axis Wide vs
Non-Wide Events HRC-S V-axis Wide vs
Non-Wide Events

Figure 2: a) Comparison of AU1 to AU2 on HRC-S for Wide and for Non-Wide events. Non-Wide events should have a tap ringing correction applied before event positions are calculated. The dashed line is the current discrimination criterion; the solid line is a suggested improvement. b) Comparison of AV1 to AV2 on HRC-S for Wide and for Non-Wide events. Non-Wide events should have a tap ringing correction applied before event positions are calculated. The dashed line is the current discrimination criterion; the solid line is one suggested improvement.

Suggested Updates to "hrc_process_events"

A few changes are required in the CIAO tool "hrc_process_events" to make use of this improved identification scheme.

Add a "switch" to select which of the identification methods to use. This switch should be set by the value of the telemetry mnemonic: 2WDTHAST
- If 2WDTHAST = 2, use the width-exceeded bits to determine which events should be corrected.
Modify the current A1 versus A2 discrimination test from a ratio to a line.
- Add a column to the ringing correction coefficients file (TRING_OFFSET) and update the coefficients (table of suggested coefficients is below).
- If A1 > TRING_THRESH12×A2 + TRING_OFFSET, apply the correction
Add code to use the width-exceeded bits in the event status rather than the A1 versus A2 relationship.
- If axis width exceeded bit is 0, apply the correction

Suggested Coefficient Updates

	HRC-I		HRC-S
	U	V	U	V
TRING_THRESH12	0.245	0.0	0.0	0.0
TRING_OFFSET	-110	0.0	0.0	0.0

Mike Juda

Last modified: Mon Mar 26 10:11:20 EST 2001


Figure 1: a) Comparison of AU1 to AU2 on HRC-I for Wide and for Non-Wide events. Non-Wide events should have a tap ringing correction applied before event positions are calculated. The dashed line is the current discrimination criterion; the solid line is a suggested improvement.	b) Comparison of AV1 to AV2 on HRC-I for Wide and for Non-Wide events. Non-Wide events should have a tap ringing correction applied before event positions are calculated. The dashed line is the current discrimination criterion; the solid line is one suggested improvement.


Figure 2: a) Comparison of AU1 to AU2 on HRC-S for Wide and for Non-Wide events. Non-Wide events should have a tap ringing correction applied before event positions are calculated. The dashed line is the current discrimination criterion; the solid line is a suggested improvement.	b) Comparison of AV1 to AV2 on HRC-S for Wide and for Non-Wide events. Non-Wide events should have a tap ringing correction applied before event positions are calculated. The dashed line is the current discrimination criterion; the solid line is one suggested improvement.