Giters

cta-observatory / ctapipe_io_lst

ctapipe IO plugin for LST prototype data

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

DRS4 delta T correction for the LST2 camera

SeiyaNozaki opened this issue · comments

commented

For the LST1, we are using the same delta T function for all of the pixels:

For the LST2-4 camera, there are two different DRS4 types depending on production batches (same as LST1 or new batch for LST2-4). From our study, it is known the delta T relation is different between those types. Delta T curve of LST-1 batch is a bit steeper than one of LST2-4 batch. In addition, ADC counts of the LST2-4 batch are almost independent of delta T above 10 ms (instead of 100 ms for the case of the LST-1 batch). Here, I attached delta T curve of both batches from quick check of LST2 camera data (5 kHz random trigger pedestal data).
image

So we need to consider how to treat this difference in the analysis codes (although pixel-wise different delta T function is used for the correction in EVB in the future). I feel that the best way is to get pixel-wise dT-ADC relation during the step of lstchain_create_drs4_pedestal_file, then load the file and apply pixel-wise delta T correction.

What do you think? @maxnoe @jsitarek @pawel21 @tysaito2008
We already have LST2 camera data in PIC (5kHz, /pnfs/pic.es/data/cta/LST/LST2/Data/ZFITS/20220531/LST-2.1.Run00205.0000.fits.fz), so we can develop the codes now and I hope it can be implemented before October, when LST2 camera commissioning test will be done at IAC.

commented

Hi @SeiyaNozaki, since the two bunches of chips will likely end up mixed in the cameras, I guess there will be not much choice but to implement it pixelwise as you wrote. The three parameters of the power-law + 4th parameter of the break of the behaviour will need to be fit for each pixel and then also stored in the output files, but I am a bit worried if the fits will be stable in particular if we need to change also the maximum time lapse.

commented

Hi @jsitarek , here you can find the status of my study using LST2 camera data (5kHz random trigger pedestal)
drs_correction_for_lst2.pdf
I am also considering that first we try to identify somehow which batch is used for each pixel, then apply the typical curve to each production batch.

commented

@SeiyaNozaki I would be in favor of a generala solution storing calibration constants for each pixel. It's not much more space but removes a lot of complexity from the application side.

The calculatation could still happen in groups of pixels that are expected to have the same behavior.

When I rewrote the drs4 baseline calibration tool using the OnlineStats class, I also had a prototype for fitting the drs4 time calibration based on filling histograms of charge vs. delta t.

I will try to resurrect this and open a pull request in lstchain

commented

Let me note that I found using this that there are also differences between the pixels of the current batch, but the differences are small enough to allow the use of a common function for all pixels.

commented

@SeiyaNozaki I resurrected the old branch and rebased vs. current lstchain master here:

cta-observatory/cta-lstchain#1017

commented

@SeiyaNozaki do you know the distribution of these batches over the new cameras? I.e. which cameras have old and new batches and if their are cameras with both types mixed?