[tof] ToaDetector does not contain real time-of-arrival

[nvaytet]

The data returned as ToaDetector contains event_time_offset + pulse_index * pulse_period.

This is not actually the 'time-of-arrival' in the strict sense, as it is still wrapped over the frame period.
We should consider unwrapping it in the future to get the true time-of-arrival.
Or give it a different name to avoid confusion.

The true time of arrival could then be used to compute time at sample by tracing neutrons backwards in time. Currently, we cannot do this using ToaDetector.

[SimonHeybrock]

Not sure I understand. Are you saying the pulse_index in your equation is the wrong one, so the time_of_arrival is offset by a small integer of pulse_period? Where to we get the wrong pulse_index from?

[nvaytet]

Hmm thanks for pointing out that the above sounded strange...
I think I managed to confuse myself again, and I also think we really need to fix the vocabulary.

After looking for too long at wrapped lookup tables, I convinced myself that to get a toa we needed to 'unwrap' the spill-over at early event_time_offset to put it back on the right hand side at large toas.

But I seem to have forgotten that those neutrons are coming from the previous pulse.

I also think the 'time-of-arrival' term is ambiguous. Do we mean

1. The absolute timestamp of when the neutron hit the detector (= event_time_zero + event_time_offset)
2. The time delta mentioned above event_time_offset + pulse_index * pulse_period

I will call number 1 "arrival_timestamp".

There are 2 things we could want to compute from the arrival_timestamp:

• what was the timestamp of that neutron at the sample (to filter events based on sample environment) which can be traced back if we know the wavelength
• what was the event_time_offset at the sample (also traced back using known wavelength from analyzer) so we can compute incident wavelength/energy from a lookup table

Number 2 would correspond to what ECDC would get if start recording monitor data in histogram mode wrapping over 2 or more pulse periods. But then we probably don't need a provider for that, as it would just be in the raw data?

[SimonHeybrock]

I mean time-of-arrival to be the absolute time of arrival, i.e., (1.)., but I had assumed that this is just a different way of what you wrote in (2.). Where is the difference? Isn't event_time_zero = pulse_index * pulse_period.

[nvaytet]

This is again probably because of bad vocabulary.
pulse_index, as it is currently defined in the tof workflow, means index within a frame. So it is always 0, unless you are doing pulse skipping where it can either be 0 or 1.

It is not the pulse number, which would give you the event time zero.

We should also use a better name.

[SimonHeybrock]

Right, then I think time_of_arrival should be defined as event_time_zero + event_time_offset, i.e., an absolute wall clock time?