search

cta-observatory / ctapipe_io_lst

ctapipe IO plugin for LST prototype data
BSD 3-Clause "New" or "Revised" License
0 stars 17 forks source link

Switch to using UCTS timestamp? #155

Open maxnoe opened 2 years ago

maxnoe commented 2 years ago

From a discussion with @FrancaCassol, since UCTS is in principle the more precise timestamp and by design the component meant to provide the timestamps, we should probably switch to just using the UCTS provided timestamp instead of the dragon counter based timestamp, at least for data after the TIB firmware upgrade that fixed most of the issues related to unreliable UCTS info in the files.

Opinions, @moralejo, @rlopezcoto?

rlopezcoto commented 2 years ago

Sounds good, but if we have to reprocess some old data, it would be great to get a check that selects the dragon counter based timestamp for data before TIB firmware upgrade

moralejo commented 2 years ago

Ok with me too. Would a runnumber-based default behaviour be fine? I understand we will still calculate the dragon timestamp, and keep checking for possible jumps in the ucts info, correct?.

maxnoe commented 2 years ago

I understand we will still calculate the dragon timestamp, and keep checking for possible jumps in the ucts info, correct?.

For now, yes. The question is what to fill into the ctapipe event.trigger.time field after that has happened

maxnoe commented 2 years ago

Would a runnumber-based default behaviour be fine?

Yes, or date. For the use_flatfield_heuristic, which has the same underlying cause I think (the TIB firmware upgrade) we check if the run was after 2022-01-01.

Let's do the same here?

moralejo commented 2 years ago

We also have recent data in which the UCTS info was not available, but ok, we will just have to override the default in those cases.