Use CameraEvent.trigger_time_s and CameraEvent.trigger_time_qns when info from UCTS in the raw files is reliable

[maxnoe]

When and if UCTS is deemed reliable, the source should switch to just use these values from the CameraEvent protozfits structure rather then all this counter stuff.

e.g.

event.trigger.time = Time(proto_event.trigger_time_s, proto_event.trigger_time_qns * 4e-9, format='unix_tai')

[kosack]

this issue is probably more for ctapipe_io_lst (and/or ctapipe_io_nectarcam), right?

[maxnoe]

Oh, sorry, yes. transferring

[moralejo]

Let me stress that this does not blame on the UCTS the lack of reliability of the information. But the fact is that for much of the LST1 data taken so far, the information labeled as ucts inside the files (trigger type, timestamp) is not reliable.

[maxnoe]

I don't want to put blame on anything or anyone. Fact is, that info currently does not reach the output files reliably.

[morcuended]

Related to these comments I think we should stress the point that @moralejo mentioned when we talk about these problems. Just quote here what Juan Abel Barrio told me:

if a UCTS timestamp dont reaches properly the Event Builider, there is a whole chain of things that can go wrong: TIB, UCTS, CDTS-Server s/w, network Switches, NICs, Event Builder h/w, Event Builder s/w.

Therefore, whenever a problem associated with the “UCTS” shows up in the data stream, he and @mdpunch propose to name it “UCTS time-stamp propagation to EVB not working or unrelieable”. I suggest changing the printed-out comments in the code accordingly.

[mdpunch]

@moralejo , @morcuended , Juan Abel,

Thanks for your understanding!

Of course the UCTS-TiCkS may also sometimes give errors, but for hunting down the cause it is probably better to leave thing open so that all of the people involved in the chain can feel concerned.