Keeping useful time records in GNSS field surveys

Time connects the evidence

A survey record contains more than coordinates. Observation times connect rover points to base logs, correction interruptions, photographs, weather notes and equipment changes. If the time convention is unclear, a useful diagnostic record can become difficult to compare with another device. Establish how the project records time before production and preserve the convention with the files rather than assuming that every displayed clock represents the same quantity.

Distinguish a device's user interface time from the time tags stored in observation files. A controller may display local civil time while raw GNSS data use another documented time system. File creation times can reflect a computer clock or a transfer operation rather than the observation epoch. Each can be useful, but they answer different questions. Label them instead of treating all timestamps as interchangeable evidence.

Continue learning A practical GNSS field checklist before recording points

Record time zone and offset

For field notes, include the time zone or an explicit offset from UTC. This is especially important when office staff, remote support and field crews work in different locations. A note saying that the correction link failed at ten o'clock is incomplete if no one knows which local convention was used. Use a consistent project format and make it easy for operators to record it correctly.

When daylight saving changes apply to a location, account for them in the workflow rather than relying on a remembered offset. For projects spanning regions, UTC can simplify comparison, while local time may remain convenient for the crew. The choice should be documented and applied consistently. Do not change the convention halfway through a campaign without recording the transition and explaining how earlier notes should be interpreted.

Continue learning Coordinating GNSS logs for drone PPK workflows

Understand GNSS time systems

GNSS data formats define their time conventions and should be interpreted using the relevant specification and processing software. GPS time and UTC are related but not identical, and other constellations have their own system definitions. Avoid manually shifting raw observation epochs based on a general assumption about the controller clock. Use supported conversion and processing tools that understand the format and preserve the original files.

When examining a discrepancy, identify which program produced each time field. A converted RINEX file, a controller export and an image metadata record may each express time differently. Keep the conversion settings and software version where relevant. This prevents a time interpretation issue from being mistaken for missing observations or a reference station outage when the records actually overlap under their documented conventions.

Continue learning Building a useful photograph log for GNSS surveys

Check clocks before the session

Inspect the controller, camera or phone clocks used for field notes and photographs. Synchronize them through the approved device procedure where appropriate and record any known offset. The aim is practical alignment of supporting records, not alteration of the receiver's raw observation time tags. A simple preflight comparison can save considerable effort when matching a photo sequence to points or reconstructing an interruption later.

If a device cannot be synchronized, take a reference photograph or note that allows its offset to be estimated transparently. Preserve the original timestamp and document the interpretation separately. Do not rewrite all file metadata without keeping a record of the change. The original evidence and the correction method are both valuable when another person needs to understand how a time based association was made.

Continue learning Pairing RINEX observation and navigation files correctly

Log operational events clearly

Record base startup and shutdown, receiver restarts, antenna changes, battery interruptions and correction source changes. Include equipment identifiers and job names. These events create boundaries that help the office assess which observations share a configuration. A timestamp alone is not enough if several receivers are operating simultaneously and the note does not identify which device or setup changed.

For an outage, record when it was noticed, the last known successful check and the time recovery was verified. Those may differ from the exact technical failure time, and the distinction should remain visible. Avoid assigning false precision to a time remembered after the event. An honest approximate interval can still guide review, while an invented exact minute can mislead the analyst into excluding relevant observations.

Continue learning A practical GNSS field checklist before recording points

Compare logs in the office

Create a common timeline using documented conversions and keep the source records intact. Place rover observations, base files, correction diagnostics and crew notes on that timeline. Look for consistent offsets before concluding that records contradict one another. If a camera clock is known to be several minutes slow, show that interpretation rather than silently changing the image files and leaving no explanation.

Check overlap before attempting post processing. Base and rover observations need the appropriate time relationship and usable common data for the intended method. A filename suggesting the same day is not enough. Inspect the actual observation intervals and any gaps. Preserve processing messages that identify missing or incompatible data, since they provide a more precise explanation than a generic statement that the software did not process the job.

Continue learning Coordinating GNSS logs for drone PPK workflows

Preserve time conventions in the archive

Include a short time note with the campaign records: field note convention, relevant device offsets, raw format definitions and important conversion steps. Keep original files alongside derived outputs with clear names. This allows a later reviewer to reconstruct the sequence without depending on the memory of the operator who happened to know that one controller displayed a different time zone.

Use consistent time records to improve routine work as well as troubleshooting. They help match photographs, identify affected points after an equipment event and explain why a repeated observation belongs to a different setup. Accurate time handling does not make a coordinate correct by itself. It makes the surrounding evidence usable, which is essential when a project needs to understand, reproduce or question how that coordinate was obtained.

Continue learning Building a useful photograph log for GNSS surveys

Matching a photograph to an outage

Imagine that a phone photograph shows a correction warning but its metadata time differs from the controller event log. First establish the phone clock convention and any known offset. Compare other photographs or a reference event before deciding that the records describe different incidents. Preserve the original image metadata and document the interpreted relationship in the review note rather than silently rewriting the photograph to fit the preferred timeline.

If the offset cannot be established confidently, report a plausible interval and the uncertainty in the association. The image can still support the description of the equipment state without proving an exact observation epoch. This distinction keeps the evidence honest. Time records are most useful when they preserve what is actually known, including uncertainty, and make the conversion steps explicit enough that another analyst can repeat or question the comparison.

Use complete dates when logging events around midnight. A time without its date can be assigned to the wrong observation file during a multi-day campaign, especially when local civil time and a raw-data convention cross the day boundary differently. Preserve the documented conversion rather than grouping files solely by their displayed calendar names.

Continue learning Pairing RINEX observation and navigation files correctly