Camera PTP timestamps: why Unix time can disappear

A camera can remain synchronized with its peers while its timestamps no longer resemble calendar time. That distinction matters when inspection records must align with production logs, reject events or other machines. Start by checking the selected grandmaster, timestamp units and time scale, rather than changing the date conversion. The procedure below separates synchronization from absolute time and helps you document a defensible mapping between camera timestamps and Unix time.

Identify what changed before changing settings

First determine whether the raw frame timestamp changed, the display conversion changed, or the camera followed a different clock. These faults can produce similar screenshots but require different fixes.

Capture the raw integer timestamp from several consecutive frames. Record the host receive time separately, together with camera identity, acquisition settings and the software version. Preserve the original integer rather than immediately converting it into a date string.

Compare differences between successive frame timestamps. If their spacing remains consistent with acquisition timing but the apparent date changes, the likely problem is the reference clock or conversion. If the spacing changes by a fixed factor, investigate tick frequency and unit interpretation first.

A host receive timestamp is not an exposure timestamp. Transport and buffering delay separate those events. For the broader distinction between independent clocks, use the guide to camera and IMU timestamp clock domains.

Check the likely causes in order

Use this table to select a discriminating test before modifying the system. The order is a practical starting point, not a guarantee about your installation.

Several causes can coexist. A source transition may change both the clock reference and a device's timestamp representation. Correct each layer independently instead of applying one unexplained constant until the date looks plausible.

Verify the grandmaster and its actual time source

PTP synchronizes clocks through a hierarchy. The grandmaster is the root of that hierarchy, while a device's immediate parent may be another clock along the path. Record both identities when the implementation exposes them.

Automatic selection does not generally mean that the camera with the lowest network address always wins. Election depends on the applicable profile, announced clock attributes, priorities and tie-breaking rules. GenICam provides a feature-access framework; it does not make every device's election policy identical.

Follow this evidence-gathering sequence:

1. Read each camera's current PTP state, grandmaster identity and domain using its documented features or diagnostic utility.
2. Inspect the intended grandmaster's configuration and upstream time source. Determine whether it is disciplined to UTC or simply distributing a local clock.
3. Check whether unexpected clocks are participating in the same domain. Include host timing services and network timing equipment where applicable.
4. Record available synchronization diagnostics, such as offset from master and path-delay estimates, with their documented units.
5. In a controlled maintenance test, remove the intended source and observe the replacement grandmaster and timestamp behavior.

A computer having internet access does not establish that it distributes UTC through PTP. Conversely, continuous internet access is not a prerequisite for maintaining a clock with a known relationship to UTC. What matters is the configured source, its current validity and the uncertainty accumulated when that source is unavailable.

Do not treat an enabled PTP setting as proof of synchronization. A device may be waiting for a source, acting as a master, or operating without a valid absolute-time reference.

Decode the raw counter and identify its event

Read the timestamp definition for the exact camera, firmware and acquisition API. A field called a raw timestamp may contain device ticks, a converted time value or another representation. Its name alone does not establish its epoch.

Establish these properties before calculating a date:

• Unit: seconds, nanoseconds or device-specific ticks.
• Frequency: ticks per second, including any documented changes when PTP is enabled.
• Reference: a defined epoch, a device-local origin or an arbitrary clock reference.
• Event: exposure start, another acquisition event, or host receipt.
• Continuity: behavior during synchronization, restart, reset and counter rollover.

Use differences to check the unit interpretation:

For a generic example, a difference of 500,000,000 ticks at 1,000,000,000 ticks per second represents 0.5 seconds. That calculation establishes elapsed time, not a calendar date.

A PTP clock can use the PTP time scale, associated with TAI, or an arbitrary time scale. Unix time normally follows a UTC-based convention rather than a continuous TAI count. Where applicable, conversion therefore depends on valid time-scale and UTC-offset information. A camera or API may already perform that conversion.

Also check how the complete system handles leap seconds or any configured time smear. Mixing different conventions can produce disagreement even when each individual clock appears healthy.

Establish an explicit mapping to wall-clock time

If the camera exposes a local counter rather than documented Unix timestamps, an application can maintain a mapping. However, that mapping needs an independently established relationship between the camera clock and the reference clock.

For a limited interval with a stable frequency, a simple model is:

The phrase “same event” is essential. Pairing a camera timestamp with the host time immediately after a blocking receive call includes exposure, transfer, buffering and scheduling delays. It is not an exact calibration point.

Use a documented clock-correlation mechanism or an independently timestamped common event where the hardware supports it. If only host receipt is available, characterize the delay and report the mapping as an estimate. Repeated measurements can reveal variability, but averaging does not automatically remove a fixed transport bias.

Store the mapping with its validity interval, uncertainty, grandmaster identity and time-scale assumptions. Start a new interval after an unqualified clock step, reset or source transition.

Preserve raw timestamps alongside converted values. That allows later correction without inventing missing timing evidence. If processing completes out of order, maintain frame identity using the methods in asynchronous vision result frame matching.

Work through a numeric example and error budget

Consider a hypothetical camera counter with a documented frequency of 1,000,000,000 ticks per second. A valid correlation establishes these values for one common event:

The camera count at the reference event corresponds to 9,000 seconds from its counter origin. That origin is not established as a calendar epoch. The externally verified correlation supplies the missing relationship.

Now consider uncertainty. Suppose the correlation uncertainty is bounded by 2 ms, and the camera's remaining frequency error is bounded by 10 ppm during free running. After 100 seconds, the additional drift allowance is:

These are illustrative assumptions, not camera specifications. A real budget must also include timestamp-event uncertainty and any relevant reference-clock error. Use measured or documented bounds; an observed average offset is not a worst-case guarantee.

Restore the intended source rather than a plausible date

Choose the repair according to the required outcome.

When you need absolute event time

Configure a documented UTC-related source and an intentional PTP election policy. Verify that the selected grandmaster actually uses that source and reports appropriate time properties. Confirm whether the camera API returns raw PTP-related counts or already converted Unix time.

Define what the application does when the source becomes invalid. Suitable responses may include marking records as time-unqualified, suspending time-dependent decisions, or using a characterized holdover interval. The acceptable behavior depends on the inspection's timing requirements.

When you need only agreement between cameras

A local grandmaster may be sufficient if relative synchronization meets the application requirement. Label stored values as device or synchronized-domain time instead of presenting them as calendar dates.

Do not add an arbitrary epoch offset merely to make a date formatter produce a familiar year. That changes the appearance without establishing absolute accuracy.

When a camera retains the previous clock value

A clock may continue near a previously acquired absolute value after the external source disappears, depending on its implementation. This explains how a local master can appear to distribute calendar-like timestamps without independently knowing UTC.

Test that behavior rather than relying on it. Distinguish a source transition without reboot from a warm restart and a complete power cycle. Use only documented reset procedures, and do not assume retained state will survive either operation.

Verify transitions and define acceptance limits

Choose acceptance limits from the process requirement. A record-correlation task allowing 20 ms of uncertainty needs different validation from a measurement requiring 100 microseconds. These are example requirements, not implied hardware capabilities.

Run tests in a maintenance environment and preserve the timing logs. Include startup, normal operation, loss of the preferred source and restoration of that source. Check for discontinuities, backward movement and changes in grandmaster identity.

Before releasing the integration, confirm:

• The recorded grandmaster matches the intended election policy.
• Timestamp units and event definitions are documented.
• Absolute-time validity is separate from relative synchronization status.
• Clock transitions create a new mapping interval when required.
• Converted timestamps remain within the chosen uncertainty budget.
• Raw counts, frame identifiers and timing metadata remain available for diagnosis.

A timestamp should not silently inherit the previous frame's validity status after a clock transition. Qualify the new state using documented diagnostics and application-specific acceptance criteria.

Check documented timing features before replacing hardware

Replacing a camera is not the first fix for an incorrect epoch conversion. Start with the area scan cameras category and camera finder only when the existing hardware lacks a documented feature your timing design needs.

The LS-CMR-0053 is a catalog example of a GigE area scan camera. Its inclusion here does not establish PTP support, timestamp units or absolute-time behavior.

The MV-CU020-90GC is another catalog example of a GigE area scan camera. Its timing implementation also requires confirmation from the manufacturer's documentation.

For any shortlist, request documentation covering supported PTP operation, election controls, timestamp events, units, time scale and behavior after losing synchronization. A GigE interface alone does not establish those capabilities.

Use the camera configurator to organize the hardware selection, or contact applications support with your raw timestamp samples, clock identities and required timing uncertainty. Those details make the next step a timing decision rather than a guess about date formatting.