Analysis of BIAUV Picture Timestamp Options

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.)

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.

  1. At start of each mission log:
    1. If accessible, record last picture name on camera; this is optional but might be useful to have in case of malfunction. [Test if accessible.]
    2. Optionally, take 3 images a known time apart (1 second?), following the process described for trigger commands below.
  2. Before each trigger command:
    1. Send GPS data with subseconds to camera before each trigger command. [Confirm centiseconds is stored in GPS metadata.]
    2. 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?). [Confirm lag is sufficient.]
    3. Command picture be taken
    4. Log time of command, and GPS string sent to camera just before the command. Optionally log an image ID.
  3. At end of mission log:
    1. Optionally, take 3 images a known time apart, following the process above.
    2. If accessible, record last picture name on camera; this is optional but might be useful to have in case of malfunction
  4. After recovery of images:
    1. Calculate actual time of image, based on GPS string plus expected offset on each image. [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.]
    2. Enter corrected GPS timestamp into reprocessed image.
    3. Optionally use the log to set the image ID in the metadata of the reprocessed image.
    4. Optionally set other metadata that is readily available and confidently known.

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.

Embedded Metadata: Embedded Subsection Data

Exif Camera Timestamp Field

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.)

GPS Timestamp Field

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.

GPS MapDatum Field

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.

GPS Latitude/Longitude Fields

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.

Exif User Comment Field

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.

GPS NMEA Input Formats

The GPS format is NMEA 0183. It provides for a GPS/Transit data set that supports centiseconds in the time field.

Latitude and longitude do not appear to have sufficient resolution for a full timestamp with centiseconds, though the stored values support it.

GPS/TRANSIT Data Containing UTC Timestamp

RMC = Recommended Minimum Specific GPS/TRANSIT Data

$GPRMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,ddmmyy,x.x,a*hh

1 = UTC of position fix
2 = Data status (V=navigation receiver warning)
3 = Latitude of fix
4 = N or S
5 = Longitude of fix
6 = E or W
7 = Speed over ground in knots
8 = Track made good in degrees True
9 = UT date
10 = Magnetic variation degrees (Easterly var. subtracts from true course)
11 = E or W
12 = Checksum

GARMIN Format Containing Map Datum

This is nominally a proprietary Garmin format. But it's possible the camera transfers it.

$PGRMM,NAD27 Canada*2F

Currently active horizontal datum