Reading the trigger times of each sector

[clara-escanuela]

I can see that we can read the sectors of the camera that triggered for a specific event in "event.trigger.tel[tel_id]" but we also have information (from the simulation) of the time each sector was triggered:

Telescope data event 100 for telescope 1: Telescope event header for telescope 1: Local count: 1, global count: 100 CPU time: 1673472768.127972000, GPS time: 0.000000000 Trigger source: 1, flags: 0500 44 triggered sectors: 2 8 9 12 14 15 21 32 34 35 41 44 45 47 72 75 81 84 86 91 92 94 96 97 98 99 100 197 200 201 202 203 254 255 256 257 258 259 260 261 264 265 308 310 at time: 68.00 68.00 68.00 68.00 68.00 68.00 72.00 68.00 68.00 68.00 68.00 68.00 68.00 68.00 68.00 68.00 68.00 72.00 72.00 68.00 68.00 68.00 68.00 68.00 68.00 68.00 68.00 72.00 68.00 68.00 72.00 68.00 68.00 68.00 72.00 68.00 68.00 68.00 72.00 68.00 68.00 68.00 68.00 68.00 ns Earliest trigger is 68.000 ns after start of simulation. Readout starts at bin 11, global time -1408.467 ns. Trigger time: 24.000 ns after readout start, global time -1384.467 ns.

I think we could include this as well. It is not much work and it is very interesting.

[kosack]

This is linked also to #855 (which includes the definition of camera modules and trigger sectors).

And we will have this information in real data as well, so useful to simulate

[maxnoe]

I don't think individual trigger sectors will be available, at least they are not part of any of the current r1 or dl0 data models.

[kosack]

We will likely have pixel sector information in the monitoring data, if not in the event data. For the events, there is a bitfield for the trigger pattern in the pixel_status, which could map to the sectors. This is not so well defined currently, however: bits 5-7 the last 3 bits are for recording pixel-wise (or sector-wise) trigger info (contents to be determined).

What will likely be monitored will be things like trigger sector multiplicity, trigger sector hit rates, etc.

[clara-escanuela]

This is linked also to #855 (which includes the definition of camera modules and trigger sectors).

And we will have this information in real data as well, so useful to simulate

So I guess we can close this issue as this problem was already mentioned before

[maxnoe]

I'd leave it open, since these are two different but related things.

The other issue is about knowing which pixels belong to which trigger patch. This one is about the trigger times of the patchea

[mdpunch]

Just a comment from the NectarCAM side:

There is no timing of the individual trigger sectors available, as far as I know. There is actually even no information on which sectors triggered. I have recently initiated a "change request" so that we can at least get a single bit that the count of the number of sectors participating in the trigger has exceeded a programmable level (which requires a change in the firmware of the Digital Trigger Crate, and somewhat of the Trigger Interface Board).

Even the knowledge of which pixels participated in the trigger is only approximate, as the FEB (Front End Board) of the module of 7 PMTs sends only "four 7-bit patterns with the output of L0 trigger discriminators" (quoting from a presentation), which are at a programmable offset to the trigger time, and I think every 4ns (possibly programmable).

It could be possible to deduce which sectors did trigger using that information, but not with 100% certainty.

I think it would be good to check with the different cameras what their capabilities are in practice (for LST and NectarCAM, probably Juan Abel Barrio could be the combined contact to ask), especially as I may have missed some wrinkle in the NectarCAM architecture.

[mdpunch]

Minor correction for NectarCAM: There is as @kosack guessed, an "L1 scaler" which gives the information on the rate of the triggers in a given sector (37 pixels, overlapping), which is useful for monitoring (but, no event-by-event information).