HiSPARC / publicdb

The HiSPARC Public Database
https://data.hisparc.nl/
GNU General Public License v3.0
8 stars 4 forks source link

Proposal: Add station position to station layout #171

Closed tomkooij closed 7 years ago

tomkooij commented 7 years ago

For calculating time offsets between station GPS clocks , using coincidences, we need to know the altitude difference between stations. Currently we use the altitudes from GPS surveys, which results in inaccuracies of several meters. This results in timing offset inaccuracies in the order of 10 ns.

For example, the altitude difference between the GPS antennae of 501 and 510 is currently about 3 meters as reported by the GPS units. While the actual difference is zero. Currently we use the GPS positions for determining time offsets.

To improve the determination of GPS timing offsets we are determining the actual altitude of the stations in the Science Park array. We need to store this (meta) data somewhere to be able to use this data.

Proposal:

We add a "location" field to the station layout. A relevant description of this field in the submission form will be necessary. When this data is available, it can be used for determining GPS timing offsets. When not, we can still use the GPS altitude.

Any thoughts of a better place to store this?

153957 commented 7 years ago

The current difference between 501 and 510 is 57.65 - 55.78 = 1.87 m, so ~6 ns. This altitude difference is taken into account when determining the station time offsets. However the altitude difference is also taken into account when reconstructing showers. These two should mostly (not perfectly) cancel each other out, relevant code: https://github.com/HiSPARC/sapphire/blob/master/sapphire/analysis/direction_reconstruction.py#L1150-L1152 https://github.com/HiSPARC/sapphire/blob/master/sapphire/analysis/event_utils.py#L165 https://github.com/HiSPARC/sapphire/blob/master/sapphire/analysis/calibration.py#L353

This would require a lot of bookkeeping, since these manually determined positions may have different start/end dates than the self-surveys, or actual station relocations.

Could increasing the self-survey time, to perhaps 2 days, help? Additionally, this problem is almost exclusively relevant for stations on top of each other, in most other cases (stations further apart) the 24-hour self-survey is accurate enough.

tomkooij commented 7 years ago

Mmmh. Interesting if these cancel each other out. However, a LiO also needs more consistent time offsets for comparing arrival times of particles, not just reconstructions.

I won't implement the infrastructure before it is determined that it is useful, so I'll wait and see.

Increasing survey time will probably not help. Sub-meter position accuracy is not possible using single frequency receivers without post processing. For post processing raw data about the carrier wave (not the C/A code) is necessary, which the Trimble Resolution T GPS cannot provide. (I checked).

153957 commented 7 years ago

Like I said, they do not perfectly cancel. In the reconstruction the shower angle is taken into account:

t_proj = ti + zi / (c * nz) vs station_offset += dz / c

tomkooij commented 7 years ago

I decided against this.

This does not (really) affect reconstructions and timing corrections can be done by postprocessing API data.

tomkooij/lio-project@c1ba750 implements a sapphire.api.Station like object that handles the altitude (timing) correction. It is slow and awkward, but it does the job.