Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better definition of timestamp based on EVB run start #159

Open
SeiyaNozaki opened this issue Nov 14, 2022 · 5 comments
Open

Better definition of timestamp based on EVB run start #159

SeiyaNozaki opened this issue Nov 14, 2022 · 5 comments

Comments

@SeiyaNozaki
Copy link
Contributor

When there is no reliable UCTS information, it is needed to compute the timestamp based on the EVB run start recorded in the Camera Configuration file (event.lst.tel[1].svc.date) with Dragon counters.

Here is my understanding of the timestamps (which might be wrong):
20221111_event_timestamp.pdf

Based on the above understanding, the difference between UCTS timestamp and run_start-time-based timestamp is <us. But an additional 1-sec difference can be added for case 2 described in the pdf.

from traitlets.config import Config
from astropy.time import Time
import numpy as np
from ctapipe.io import EventSeeker
from ctapipe_io_lst import LSTEventSource

from ctapipe_io_lst.event_time import (
    calc_dragon_time,
    time_from_unix_tai_ns,
    uint64_diff,
    S_TO_NS
)

config = Config({
    'LSTEventSource': {
        'input_url': '/fefs/onsite/data/20221113/LST-1.1.Run10499.0000.fits.fz',
        'apply_drs4_corrections': False,
        'pointing_information': False,
        'trigger_information': False,
    }
})

source = LSTEventSource(config=config)
seeker = EventSeeker(source)
event = seeker.get_event_index(0)

# UCTS time stamp
ucts_timestamp = time_from_unix_tai_ns(event.lst.tel[1].evt.ucts_timestamp)
print("UCTS timestamp: ", ucts_timestamp.utc.datetime)

# EVB run_start time + Dragou counter
run_start = Time(event.lst.tel[1].svc.date, format='unix')
evb_runstart_time = np.uint64(S_TO_NS * run_start.unix_tai)

local_clock_time_sec = np.min(event.lst.tel[1].evt.local_clock_counter) * 7.5e-9
local_clock_time_sec_uint = np.uint64(local_clock_time_sec)

dragon_pps_counter = np.min(event.lst.tel[1].evt.pps_counter)
dragon_tenMHz_counter = np.min(event.lst.tel[1].evt.tenMHz_counter)

dragon_timestamp = time_from_unix_tai_ns(
    calc_dragon_time(
        pps_counter = local_clock_time_sec_uint,
        tenMHz_counter = dragon_tenMHz_counter,
        reference_time = evb_runstart_time,
        reference_counter = np.uint64(0)
    )
)

print("dragon timestamp: ", dragon_timestamp.utc.datetime)

print("difference [ns]: ", uint64_diff(ucts_timestamp.unix_tai * S_TO_NS, dragon_timestamp.unix_tai * S_TO_NS))

then, the results are:

UCTS timestamp:  2022-11-13 19:31:48.632050
dragon timestamp:  2022-11-13 19:31:48.632050
difference [ns]:  256
@maxnoe
Copy link
Member

maxnoe commented Nov 16, 2022

Thanks @SeiyaNozaki this looks promising indeed.

Is there any way to automatically detect this difference? It looks like a rounding issue. E.g. might int(counter + 0.5) work for both cases? So rounding instead of truncating?

@SeiyaNozaki
Copy link
Contributor Author

The difference can be detected.
For case 2, the increment of int(Dragon local clock counter) should happen before the first PPS increment.

Here are some example of the evolution of counters/timestamp.

run10499_case1

run10500_case2

@maxnoe
Copy link
Member

maxnoe commented Nov 16, 2022

Ok, but I guess there is no way to tell with only the first event?

@maxnoe
Copy link
Member

maxnoe commented Nov 16, 2022

We could rethink the run summary using this information, which is anyway needed to make it work for the later subruns, correct?

@SeiyaNozaki
Copy link
Contributor Author

yes, correct! I will try to implement it to create a run summary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants