Dear @balagura, thank you for your comment. All the pedestal subtraction methods have a negative impact on the +2, +4 bxids (and potentially later). You may build other methods that will follow the pedestal on a longer time scale and that will not lead to an "undershoot", as you mention it. But, they will have potentially other bad behaviors, like not following some high frequency changes in the pedestal. And this will also have an impact on the data, sometimes more difficult to quantify. The purpose of the second method we implemented was to reduce the impact of the "undershoot" produced by the first one. And indeed this was more and more needed when getting to larger mus. Which is what you observe. You mention that you have more information on what you saw : I would be interested to get it and to have a discussion on this soon with you. Concerning the LLT information, it is calculated in the FPGAs of the FEBs and the data are in the CALO banks. I don't think that there is any issue on this. The problem is that, unlike the calo DAQ data which are calibrated in the decoding/reconstruction, the LLT calibration has to be done in the FPGA, before making the sums. And we don't have the calibration for the LLT at present. This is missing and this requires work. So, we have to see whether it is useful to spend time on the LLT calibration or not. The calibration constants have to be filled into the FE boards with the slow control (wincc). Then, the LLT may potentially be useful and would provide decent information according to me.
Frederic Machefert (fa623e9f) at 14 Feb 17:15
update CMakeList.txt in CaloFuture/CaloFutureMoniDst
... and 1 more commit
Frederic Machefert (945b047e) at 14 Feb 17:11
update python script for digit monitoring (ntp)
... and 532 more commits
I think that Jean-François @jmarchan, being in charge of the calo software, should be included in the discussion if this is not the case.
Concerning the FPGA, the problem is not a problem of resources, but mainly of access to the ADC values, at least if we plan to do a 2D suppression which is the aim ultimately. The 2D suppression cannot be done in FPGAs. Or even in the TELL40. For the same reason.
A 1D zero suppression, if it consists simply it keeping the ADC values just above a certain threshold (before any kind of calibration) could be done in a FPGA. But, it is rather late. We would have to make a new firmware version, reload the FEBs... The best would be to do it at the level of the TELL40.
But of course, we don't have the bandwidth in the optical links to send both 1D and non-zero suppressed data. And to do the 2D, we would need the non-zero suppressed data according to me. Unless, we neglect the biais that could eventually be produced...
So to conclude, I don't think that this is realistic to think about the FPGAs for the zero suppression. And probably also to think of the TELL40 for this task.
Frederic Machefert (23eb152d) at 05 Oct 14:25
Modify ntuple field names and add the channel number/col/row on FEB
... and 252 more commits
Frederic Machefert (905d4b13) at 13 Jul 08:16
comment some useless lines