Only one digi per pixel, therefore no pixel PixelDeadTime used
Time of first RichPoint in unsorted container was used as digi time for each pixel
Digi times need to be 'correct' since HT ring finder used time information also in EventBased mode, also for ML
TimeBased:
Time of first RichPoint in unsorted container [Event by event] was used as digi time for each pixel
Signals were already digitized before all potential signals were known (e.g. InterEventNoise)
Also caused digis being in the deadtime, bacause the FiredPixelMap only stored 1 time for each pixel
Time smearing at point level also caused Links to not be added as intended
Changes for the Rich digitizer:
buffer signals until all potential signals are added and then process (similar to Sts and Trd)
Time smearing is added at digi level
resulting in fPixelDeadTime being only a soft deadtime, the deadtime on digi level is approximately fPixelDeadTime - 2 * 5 * fTimeResolution (5 sigma for one digi being potentially time smeared into the deadtime)
addition of fLinkAdditionDuration [default to fPixelDeadTime], adding Link only in a certain duration after digi creation
since adding all Links in the full deadtime might have an impact in efficiency calculations, especially for high rates [needs to be analysed]
addition of Crosstalk (fully functional with MR!1258 (merged))
addition of clusters from charged particles directly hitting pmts (turned off by default)
removal of hard-coded values and addition of more setter functions
removal of MaxDigisPerPmtCut and functionality (might be reintroduced at a different point in the reco chain, e.g. HitProducer or Reco)
DigiQa class, to compare simulation and real data, based on digi deadtimes and distance to eachother to compare crosstalk