Negative values in R0 data frame during the pedestal calculation

[SeiyaNozaki]

It seems a few capacitors (2-3cell/(4096cel * 1855pix * 2gain)) have too small pedestal values (<50ADC).
For those capacitors, R0 data would be possibly negative during the pedestal calculation with time-lapse correction enabled.
(It is possible that raw data of those capacitors have already zero...)
The data type of R0 is uint16, so those negative values are converted to too high ADC counts, which will be saved in a pedestal table...

I'd like to avoid such a situation... possible solutions are:

1. convert the data type of R0 waveform into int16 (or float?) during pedestal computation
2. just fill zero if R0 data after time-lapse correction is negative

Do you have any opinions?

Related redmine ticket is:
https://forge.in2p3.fr/issues/44184

[moralejo]

I don't understand what is the original content of those cells. Do they have baselines inconsistent with those obtained from DRS4 calibration?

In any case, we should absolutely avoid that a negative value becomes a large one. Set it to zero instead.
Do you think it is relevant to fix this before next reprocessing, or is it so rare that it is not urgent?

[SeiyaNozaki]

Sorry, let me clarify:

Concerning the previous post, pedestal data (r3889) was taken without baseline correction.
So, the pedestal table which is currently used in EVB was created with this pedestal data. There is no extra offset (400), so a few capacitors would be zero at the raw level (, but I never noticed it...!). Then, those negative values after offline time-lapse correction were converted to high values, which increased the pedestal value of those capacitors for EVB baseline correction.

Then, we saw extremely high ADC counts(~65550) in R0 data with EVB baseline correction based on this pedestal table, which made three pixels outliers in the calibration script. After EVB's baseline correction, those capacitors had negative value due to high pedestal and also converted to extremely high values already at the EVB stage.

I produced the pedestal table with the previous version of lstchain, and this table should work in EVB.
We try to take pedestal data with this pedestal file soon. If it works, the data of those capacitors will be correctly subtracted and extra 400 counts were added in EVB. So, there should be also no problem after this stage.

So, this is not an urgent issue, but we should fix it to produce a pedestal table for EVB in the future.

[moralejo]

Ok, thanks for the clarification! In any case, let's implement a fix straightaway, to avoid that a negative value becomes a large positive one. Can you take care of it @SeiyaNozaki ?

[SeiyaNozaki]

Let me take care:)