Dear Colleagues,

In thinking at Nevis about the sums required in the Run IIb L1Cal Trigger
Algorithm Boards, we have run across a potential problem in the way
noise is treated in the current design. Perhaps someone has already
thought about this and can reassure us that it's actually not a
problem. However, we thought that it would be wise to air this
question, since it could have a large impact on the TAB design. Please
read the following carefully and send any comments to Hal
(evans@nevis.columbia.edu). We should discuss this issue in our next
Run IIb L1Cal meeting on Dec. 12 - so mark that date on your
calendars!

Now to the question...

If we understand the ADF correctly, it produces as output for the TAB
for each Trigger Tower and for each BC, either:

  a) a pedestal value (say 8 ADC counts, for example) if that BC does
     not correspond to a peak in the analog input from the BLS
  b) the result of the digitial filter, decimated appropriately, if a
     peak has been detected.

Peak detection is done using 3 decimated ADC samples, corresponding to
1.5 BC in time.

Possible problems arise from BC's where a peak has not been detected
by the ADF, and therefore the output to the TAB is set to the
pedestal. Setting these outputs to a fixed value involves loss of
information, which can cause problems when summing large numbers of
TTs to form, e.g., missing energy, or hadronic vetos of EM energy
deposition.  These problems fall into two categories.

  1) BC's where physical signal in a TT is still rising or falling from
     a real energy deposition. This is probably not a problem since we
     want to associate the energy from a specific beam crossing only
     with that BC, and not with those before or after.
  2) BC's where there is no physical signal in the TT. In this case,
     it is much more likely that a peak will be found for signals that
     fluctuate above pedestal than for those that fluctuate
     below. The current algorithm, therefore, biases us to "positive"
     noise fluctuations. This could be dangerous since we want to set
     hadronic vetoes as close to the nominal noise level as possible.

Both of these problems are quite hard to simulate because they require
information about BC's before and after the current one to be
available. Perhaps experience with the current system can tell us
whether these problems deserve attention.

If it turns out that we do have to address this issue, we have thought
of two possible solutions.

  A) Only accept those peaks from the digital filter that are
     several sigma above noise and set everything else to zero. This
     is certainly not what we have simulated up to now - so we would
     have to study it carefully before choosing it.
  B) Ask the ADFs to send the TAB (decimated) outputs of the Digital
     Filter every BC, as 8-bit data but add a 9th bit to each word
     indicating whether that BC corresponds to a peak or not. This is
     the most flexible solution but requires some work on the ADF end
     and non-negligible additional resources for the TAB sliding
     windows FPGAs.

If anyone has other ideas, we would, of course, be happy to hear about
them.