Specim NavSync

The Specim family of instruments employ more or less the same method for synchronisation of camera imagery to navigation, by tying the frame capture timing to GPS time, which can then be used to look up the attitude and position of the aircraft from the navigation system.

A "navsync" box receives the GPS PPS (pulse-per-second), an input ​GPS NMEA serial stream (via RS232) for realtime navigation and the frame sync pulse from the camera. The navsync box outputs the NMEA stream with additional messages inserted into gaps in the stream. These messages and the realtime stream continue on to the host digitisation and control computer, which ultimately records them in a .nav file.

The method for detecting a gap in the serial stream is unknown, but may involve a buffer of the relevant number of characters (to identify a large enough space) and thus potentially also a delay of the normal message stream. This should have no real effect, though the navsync output should not be used as an input into any other instruments as a precaution. Alternatively, it may rely on well known spacing of NMEA messages (no delay, but runs the risk of overwriting/corrupting other custom/unexpected messages in the stream).

Version 1 (2005-2010 ish)

The fractional-seconds time difference between the first frame sync pulse following the "start recording" command from the control computer and the next GPS PPS is measured and recorded. This gives a single offset from the PPS. The timing of subsequent frames is determined by the frame rate of the camera (generally quite stable).

For ARSF's combination of instruments and navigation systems, a small offset of up to +/- 0.05 between the derived time and the visually-best-match was noted, and required per-flightline manual correction. After investigation, this spurred the development of a second iteration of the navsync box.

The file format is different for these files (binary) and were not necessarily created using NMEA output messages.

Version 2 (circa 2010 onwards)

Essentially the same as version 1, but with a frame-timing timestamp for every PPS. If a frame pulse occurs too close to a PPS, it is ignored in favour of the next one. This eliminates the possibility of drift/inaccuracy in the framerate timing causing navigation slippage or errors. Results show the framerate timing is robust and stable in general.

However, the issue with the small offsets remains present, indicating the error is not to do with slippage.