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

Investigate importance of the 'time_delta' value in HiSPARCEvent messages #31

Open
153957 opened this issue May 29, 2015 · 3 comments
Open

Comments

@153957
Copy link
Member

153957 commented May 29, 2015

HiSPARC Event messages (CIC) contain a time_delta value. This is currently not sent to the datastore, it contains the difference in the timestamp for the Master and Slave events.

This could/should be used to correct time differences between master/slave traces.

We currently assume this to be fairly constant and correct for it by doing the 'detector_offsets' correction.

We should determine:

  • If this time_delta is 'constant' for a given master-slave combination or does it changes over time
  • What is the typical distribution from event to event, and over longer periods.

For instance, the 'jump' in offsets for the slave detectors in May 2012 is explained by the switch to HiSPARC III electronics. So there is probably a different offset for that Master-Slave combination, which can probably be found in the time_delta.
unknown

The time_delta should be an integer number of nanoseconds, basically the time difference between the extended timestamp of the master and slave.

TODO: check if the 'correction' in the firmware partly corrects this offset, so is it already taken into account or not.. (since a certain version of the firmware a correction was added to make the master/slave data more inline.. this requires a bit more investigation).

@153957
Copy link
Member Author

153957 commented Jul 2, 2015

Added export of the values (with timestamp to find the corresponding events) to the HiSPARCEvent.py in branch time-delta. I will run this on station 501 for some time.

@153957
Copy link
Member Author

153957 commented Aug 18, 2015

Tested with a pulse generator with 4 equal length cables to each input channel
t_M = arrival time in Master
t_S = arrival time in Slave
t_δ = time_delta (i.e. difference between Master-Slave extended GPS timestamps)

dt_time_delta

t_δ follows the offset between Master and Slave, and helps to decrease the width of the t_M - t_S distribution and move it close to 0 ns. However, the daily determined detector offsets also compensate for that. Perhaps using the same threshold for the arrival times and trigger can give a slightly more accurate reconstruction.

@153957
Copy link
Member Author

153957 commented Aug 18, 2015

Here are plots of the time delta distribution and moving average for almost two days of data for 501 during normal data taking (no pulse generator).

time_delta_510
moving_average_time_delta_501

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

No branches or pull requests

1 participant