<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Untitled Document</title>
</head>

<body>
<h1>Analysis of BIAUV Picture Timestamp Options</h1>
<p>There appear to be several options for sub-second timestamp encoding. As it
  turns out, it appears to be possible to submit centiseconds in the GPS string,
  the camera appears capable of reporting GPS time to this accuracy, and the
  camera can report its time of the image (in camera time) to the centisecond.
  (Details of this and other relevant metadata, and GPS commands, are appended
  below.)</p>
<p>With this knowledge, the best option appears to be as follows. Steps 1 and
  3 are safeguards to make life easier if, say, the camera clock drifts badly,
  or our GPS time resets during the mission. But they shouldn't actually be necessary.</p>
<ol>
  <li>At start of each mission log:
    <ol>
      <li>If accessible, record last picture name on camera; this is optional
        but might be useful to have in case of malfunction. <em>[Test
        if accessible.]</em></li>
      <li>Optionally, take 3 images a known time apart (1 second?), following
        the process described for trigger commands below.</li>
    </ol>
  </li>
  <li>Before each trigger command:
    <ol>
      <li>Send GPS data with subseconds to camera before
        each trigger command. <em>[Confirm centiseconds is stored in GPS metadata.]</em></li>
      <li>Wait enough time for string to be in camera (65 chars / 4800baud /
        10bit/char  = 65 chars / 480 char/sec = 0.135sec) and processed (0.1sec?). <em>[Confirm
        lag is sufficient.]</em></li>
      <li>Command  picture be taken</li>
      <li>Log time of command, and GPS string sent to camera just before the
        command. Optionally log an image ID.</li>
    </ol>
  </li>
  <li>At end of mission log:
    <ol>
      <li>Optionally, take 3 images a known time apart, following the process
        above.</li>
      <li>If accessible, record last picture name on camera;
      this is optional but might be useful to have in case of malfunction</li>
    </ol>
  </li>
  <li>After recovery of images:
    <ol>
      <li>Calculate actual time of image, based on GPS
        string plus expected offset on each image.<em> [For first few missions,
        compare camera's internal centisecond-level timestamp with logged GPS
        timestamp, looking in the differential for jitter, lag, and drift within
        reasonable limits.] </em></li>
      <li>Enter corrected GPS timestamp into reprocessed image.</li>
      <li>Optionally use the log to set the  image ID in the metadata of the
        reprocessed image.</li>
      <li>Optionally set other metadata that is readily available and confidently
        known.</li>
    </ol>
  </li>
</ol>
<p>Depending on the analysis for step 4.1, either a fixed offset from GPS time
  can be used on future missions, or an additional timestamp calibration can
  be determined for each set of images so that the camera time can be used to
  more precisely offset the GPS time.</p>
<h2>Embedded Metadata: Embedded Subsection Data</h2>
<h4>Exif Camera Timestamp Field</h4>
<p>There is an Exif field within the picture metadata that captures centiseconds
  for each picture. (This number is associated with the camera time, not the
  GPS time.)</p>
<h4>GPS Timestamp Field</h4>
<p>The GPS Timestamp field is a triplet of ratios; the first two denominators
  are 1, so hours and minutes are integers; the seconds demoniator is 100. So
  it appears centiseconds in the GPS string may be entered into the metadata
  of the picture.</p>
<h4>GPS MapDatum Field</h4>
<p>The GPS MapDatum field is a string of 9 bytes (10 including terminator). This
  is sent with a 'Garmin proprietary' command; not clear if camera processes
  that.</p>
<h4>GPS Latitude/Longitude Fields</h4>
<p>Latitude and longitude have a similar structure, but are assigned according
  to the format of the input. (For example, if the input minutes of latitude
  is 59.296, the denominator might be 1000, and the numerator 59296.) Certainly
  between them we could get a representation for centisecond-level time encoded.
  Less desirable because metadata is 'wrong' in the raw images, but this can
  be fixed in processed images.</p>
<h3>Exif User Comment Field</h3>
<p>There is a user comment field in the Exif metadata area. The camera may support
  entering comments via one of its command interfaces (PC or USB), but I didn't
  check this out.</p>
<h2>GPS NMEA Input Formats</h2>
<p>The GPS format is NMEA 0183. It provides for a GPS/Transit data set that supports
  centiseconds in the time field. </p>
<p>Latitude and longitude do not appear to have
  sufficient resolution for a full timestamp with centiseconds, though the stored
  values support it.</p>
<h4>GPS/TRANSIT Data Containing UTC Timestamp</h4>
<p>RMC = Recommended Minimum Specific GPS/TRANSIT Data</p>
<p>$GPRMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,ddmmyy,x.x,a*hh</p>
<p>1 = UTC of position fix<br />
  2 = Data status (V=navigation receiver warning)<br />
  3 = Latitude of fix<br />
  4 = N or S<br />
  5 = Longitude of fix<br />
  6 = E or W<br />
  7 = Speed over ground in knots<br />
  8 = Track made good in degrees True<br />
  9 = UT date<br />
  10 = Magnetic variation degrees (Easterly var. subtracts from true course)<br />
  11 = E or W<br />
  12 = Checksum </p>
<h4>GARMIN Format Containing Map Datum</h4>
<p>This is nominally a proprietary Garmin format. But it's possible the camera
transfers it.</p>
<p>$PGRMM,NAD27 Canada*2F</p>
<p>
Currently active horizontal datum</p>
<p>&nbsp;</p>
</body>
</html>
