Specim synchronisation error

[mggr]

Descriptive email from Ben to Bill (4/Mar/2009):

We were (still) trying to track down our Vocals offset problem and we think we stumbled across something else. We used CaliGeo to process a line that had had a timing error in it when we'd processed it using the az suite, and CaliGeo didn't produce a timing problem.

We noticed that in the bit where Caligeo is looking for sync the message it finds has a time delay of 548ms, which matches the 548 in the "Navsync Timing" line on the line 5 header file. The previous sync message it found (and discarded) had a time delay of 119ms, which matches the Navsync Timing for line 4. Azimport for that line found a specim sync message offset of 0.119, which suggests to me that it actually picked up the sync message for line 4 rather than 5. Can you take a look at this when you get a chance please? Let me know if I can send you any additional test data. 

[mggr]

Ben further noted that the error was possibly due to the search window being off by 14 seconds (UTC/GPS offset in 2008).

Basically, the (gps) time being used as the approximate sync for that line is 41215, this coming directly from the header file (I think). CaliGeo lists the earlier sync signal as being at 41183 seconds (32 seconds earlier, outside the 25 second search window we usually use), and the later one at 41217 seconds (2 seconds out). Azimport, on the other hand, lists them as 41197 (18-and-a-bit out) and 41231 (16 out) seconds respectively - both 14 seconds after the time CaliGeo gives.

Basically, it looks like azimport is converting the nav sync message timings to UTC (hence the 14-second increase), and then comparing that to the GPS time from the header file. That's why Sg 5 doesn't work, Sg 15 doesn't work but Sg 16 does (because the nav signal that was 2 seconds away got shifted to 16 seconds), and why Sg 19 goes back to picking up the wrong sync message (because after rounding, the 33 second initial difference is reduced to 19).

[mggr]

Bill found the problem in the mismarked Specim files - they say "GPS time" but are actually UTC, hence the offset.

Fixed in release 231, azspec 1.2.6 and azimport 2.3.4.

[mggr]

There was a followup conversation with Specim about the issue and other related navigation curiosities - these will appear in another ticket if appropriate.