jbrzusto
commented
8 years ago Brackets for this period come from valid dates in previous and next boot sessions:
> library(lubridate)
## latest valid date in boot session 33:
> pre = ymd_hms("2016-07-25T10-30-39.883") - 82.2860 + 102.3223; print(pre)
[1] "2016-07-25 10:30:59 UTC"
> post = ymd_hms("2016-07-28T21-04-05.5330"); print(post)
[1] "2016-07-28 21:04:05 UTC"
> post - pre
Time difference of 3.439648 days
> span=diff(as.numeric(c(pre, post))); print(span)
[1] 297185.6
## mean of gaps between boot session 34 and neighbours
> (span - 297018.1582) / 2
[1] 83.72775
## so the boot time for session 34 is that much after "pre"
> boot34 = as.numeric(pre + 83.72775);print(boot34)
[1] 1469442743.647
## the timefix, which will consist of a GPS record sandwiched by bogus
## pulse records, has this timestamp:
> boot34 + 297018.1586
[1] 1469739761.8056The fixed file Walsingham-1614BBBK1666-000034-2000-01-04T10-30-18-1583P-all.txt looks like this:
# time fix based on dates of previous and subsequent boot sessions
# offset freq of 100 kHz and sig and noise of -200 dB ensure these pulses will be discarded.
p1,297018.1585,100,-200,-200
G,1469739761.8056,42.6353409,-80.5576264,239
p1,297018.1587,100,-200,-20083.7 seconds is close to the SG boot time, so our fix should be fairly accurate; probably under a minute or two. (Note that this receiver is recording pulse timestamps from the MONOTONIC clock.)
This has 3.4 days (297018.1582 seconds) of data from between July 25 and July 28, 2016.