Skip to content

Wacky TOA Values

Tom Eichlersmith edited this page May 29, 2025 · 6 revisions

This was due to a bug in the firmware.


This has been seen across a variety of pflib versions most prominently v3.0.0 and v3.1.0. The main reason this occurs is because no additional configuration parameters have been applied which would have given the TOA a reasonable threshold. i.e Its as if a pedestal run DAQ -> PEDESTAL was done after the parameters were cleared ROC -> HARD_RESET (but there was enough time for ambient noise to start triggering the TOA)

Problem

Seeing multiples of 128+4 and/or pseudo-random values in the TOA field of the samples.

Explanation

The core issue is that the TOA threshold is too low. When the TOA threshold is too low, the TOA can be triggered by normal electronic noise. To add to this issue, there is some feedback in the system where the TOA firing adds more noise into the system (which can then trigger more TOAs to fire). The actual 128+4 pattern comes from some internal aspects of how the TOA value is determined.

Solution

The long term solution is to actual tune the toa_vref parameter so that the TOA doesn't fire on normal electronic noise. This can only be done after tuning the pedestals, so in the short term, you should use the mask_toa parameter to disable the TOA entirely. The mask_toa parameter actually masks the discriminator on the chip so it prevents the TOA from firing.

Since this feedback loop is the main cause of TOAs firing in this situation, I (Tom) have observed at UMN all of the TOAs collapsing to 0 (their unfired value) after only setting mask_toa=1 for a single channel.

Clone this wiki locally