Dear Hal, Dear all, > > 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. Yes, but this description is a bit short. What I have simulated and coded so far in the ADF is: - An 8-tap FIR - A 3 point peak detector followed by a 1:2 decimator - A Look Up table for final Et output This hardware does the following: - If a peak was detected, then the ouput of the FIR drives the LUT that produces the final Et result; - Else the hardwired value 0x000 drives that LUT, which (likely) will produce a 0x00 at its output. So what you get for each beam crossing and each channel is either 0 or the Et value calculated by the FIR if it is a local peak. If we feel that we also want to code some negative energy values, we may use an offset binary coding scheme where both 0 and the calculated peak are shifted by a few LSBs. I have the feeling that this does not bring issues because the shift equally applies to both the 0 value and the calculated peak. Hence it is more a question of number representation and it does not correspond to setting a signal to a given pedestal. > Peak detection is done using 3 decimated ADC samples, corresponding to > 1.5 BC in time. > This is not exactly what happens. The ADC runs at BCx4 and a 1:2 decimation is made before the convolver. Hence the convolver runs at BCx2. Because we want only one value per BC, an additional 1:2 decimation is needed. In the current design, that decimation is placed after the peak detector. Selecting which of the 2 results is kept is programmable on a per channel basis, but is static (i.e. one cannot decide for each beam crossing which sample to keep). So the peak detector effectively operates on a 0.75 BC window. Whether the decimator should be placed before or after the peak detector, and whether a decimation scheme based on something more intelligent than a static choice is beneficial or not is an interesting problem that I have not addressed. The current design is what I described above, but it can certainly be changed if another scheme brings improvements. What I have included so far as programmable features that do not need FPGA reconfiguration is: - the possibility to turn-off the peak detector; i.e. the output of the FIR is always driving the final Et LUT table; - the possibility for each channel to select which of the odd or even numbered peak detector outputs are used to drive the final LUT. > 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. > This does not seem clear to me: if we say that the value 0 GeV is coded by hexadecimal value 0x07, the sum of N towers should be compared to a threshold that is offset by N times 0x07. Is that rationale too simplistic? > 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. > This is not very clear to me. The chain is a bit more complex than what is described above and we should also include the analog chain in the discussion. I just sent a descrition of that hardware to all of us. What is relevant in that discussion is summerized here. The analog input signals are AC coupled to the ADC driver. The ADC driver performs a programmable zero-adjust of the signal before driving the ADC chip. The shift is a constant voltage generated by a DAC; it is programmable within +1/4 -1/4 of the full ADC scale. Hence a null differential variation at the input (remember we are AC coupled...) can be set to produce a non-null code at the ouptut of the ADC. Hence before the digital filter, we can already offset each ADC sample by a constant value, and this can be used to code a few values of negative energy. The output of the convolver will be non-null in that case for null-variation of the analog input, but the peak detector and final LUT should take care of that. If we have a fluctuation of "negative" energy that causes a peak, I have the feeling that it will be detected by the peak detector with the same accuracy (or inacurracy...) that a similar fluctuation of "positive" energy. > 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. > First I would like to better understand whether there is an issue or not, and in the latter case if it is not already taken care of by the parameters we can play with. > Regards - Hal > > -- > ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v > | Hal Evans | > | evans@nevis.columbia.edu | > | Physics Dept. Nevis Labs | > | Columbia University PO Box 137 | > | 538 W 120th Mailcode 5215 136 S Broadway | > | New York, NY 10027 Irvington, NY 10533 | > | Tel: (212)854-3334 (914)591-2815 | > | Fax: (212)854-3379 (914)591-8120 | > v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^ >