Camera frame rate measurement from timestamped frames

A camera viewer can show a changing frame rate while your application reports a steady value, without either measurement describing the same thing. One may measure camera timestamps; another may count delivered buffers or displayed images over a rolling window. This troubleshooting procedure helps you establish the camera’s cadence, verify timestamp conversion, and locate differences introduced by transport, processing or display. Start with recorded timing evidence rather than assuming the viewer or application is wrong.

1. Identify what each frame-rate number measures

The most likely cause of disagreement is a difference in measurement definition. Before changing camera settings, identify the event, clock and averaging window behind each number.

Ask whether the viewer counts acquired, received, processed or displayed frames. Also check whether your application reports a measured value or simply reads a configured frame-rate setting.

A stable setting is not proof of stable delivery. Conversely, an irregular display is not proof of irregular exposure timing. The related frame-arrival jitter troubleshooting procedure explains how to separate camera timing from host arrival effects.

2. Verify timestamp units before calculating anything

Obtain timestamp semantics from the manufacturer’s documentation or documented API metadata. GenICam compatibility alone does not establish a universal timestamp unit or event definition.

Confirm these details:

• Whether the returned value represents ticks, nanoseconds, microseconds or seconds.
• Whether the timestamp marks exposure start, exposure end or another documented event.
• Whether it comes from the camera, transport layer or host.
• Whether a tick frequency is available and whether it can change.
• Whether timestamps reset, wrap or change behavior during synchronization.

For an integer counter with a documented tick frequency, calculate elapsed seconds as follows:

If the documented unit is nanoseconds, divide the timestamp difference by 1,000,000,000. Do not multiply by that number when converting nanoseconds to seconds.

Subtract integer timestamps before converting the difference to floating point. Converting large absolute timestamps first can discard precision needed for short intervals. Account for rollover only using the documented counter width and behavior; split the record if the interpretation is uncertain.

Do not mix a camera timestamp with a host timestamp in the same subtraction. For comparisons across clocks, use the separate procedure for mapping camera timestamps to host time.

3. Measure elapsed time across multiple frames

A single reciprocal interval is useful for spotting variation, but it is a poor substitute for a longer observation. Begin with a contiguous sequence of timestamped frames and retain their frame identifiers.

For a sequence without missing frames:

There are fewer intervals than frames because the first frame establishes the starting timestamp. For example, 61 frames spanning 60 seconds contain 60 intervals:

Using 61 / 60 would produce approximately 1.017 frames/s, an error caused entirely by counting endpoints incorrectly.

This formula differs from counting events inside an independently timed window. For that method, divide the number of events inside the window by the window’s duration. Both approaches can be valid, but their boundary conventions must remain distinct.

Do not average reciprocal intervals as the overall rate

Suppose two consecutive intervals are 0.60 seconds and 1.40 seconds. Their individual reciprocal rates are approximately 1.67 and 0.71 frames/s. Averaging those rates gives about 1.19 frames/s.

The elapsed-time calculation gives a different answer:

Use total intervals divided by total elapsed time for the overall cadence. Report interval statistics separately: mean, minimum, maximum and, for a sufficiently large sample, useful percentiles.

At a nominal rate of 1 frame/s, a 60-second observation is a useful first check. Follow it with a longer recording if the symptom is intermittent. A long-term mean can conceal a pause followed by a burst, so keep the interval sequence rather than only its average.

4. Check whether frames are missing or merely delayed

Timestamp spacing alone cannot always distinguish slow acquisition from missing images. Record the documented frame identifier or acquisition counter when available.

Consider a received sequence whose identifiers advance from 100 to 102. A timestamp interval twice the usual length might represent a missing received frame rather than a change in camera cadence.

If documentation confirms that a counter increments for every acquired frame, the counter difference can support an acquisition-rate estimate:

Do not apply this interpretation to an arbitrary buffer index. Counter resets, rollover and implementation-specific behavior must also be resolved.

Record a monotonic host timestamp as soon as the application receives each completed buffer. Compare differences within the camera clock and within the host clock separately.

• Regular camera intervals with irregular host intervals suggest delivery or scheduling variation.
• Irregular camera intervals with continuous frame identifiers suggest acquisition-event or camera-clock variation.
• Identifier gaps suggest missing frames, discarded buffers or incomplete logging, subject to counter semantics.
• Regular delivery with irregular display updates points toward the presentation path.

Preserve the association between each image, identifier and timestamp. The guide to matching asynchronous results to frames covers failures caused by separating image data from its timing metadata.

5. Separate synchronization transitions from steady operation

When PTP synchronization is enabled, record synchronization status alongside the frame log. Do not assume timestamps collected during startup or a clock transition belong to one uninterrupted timing segment.

Depending on the documented implementation, synchronization can adjust the timestamp clock, alter its rate during convergence, or introduce discontinuities. These possibilities do not prove that the physical exposure cadence changed.

Divide the evidence into clearly identified segments:

1. Startup before the documented synchronized state.
2. Stable synchronization under unchanged operating conditions.
3. Any loss of synchronization, reference-clock change or reconvergence.

Calculate cadence within each segment before calculating any combined result. Flag zero or negative timestamp differences rather than silently treating them as valid frame intervals. A positive clock discontinuity also needs investigation; positivity alone does not make an interval trustworthy.

PTP aligns participating clocks within the limits of the system. It does not, by itself, prove simultaneous exposure or establish what a frame timestamp represents. For exposure alignment across cameras, use the separate multi-camera exposure-timing verification guide.

6. Run controlled tests in order of probability

Keep acquisition settings unchanged during the initial comparison. Change one measurement component at a time so the result remains interpretable.

1. Compare identical observations. Use the same frame sequence, observation period and rate definition. Recalculate the application result from the saved raw timestamps rather than trusting its on-screen value.
2. Validate conversion. Retain raw timestamps and the documented conversion factor. Check that an interval expected to be near one second converts to approximately one second.
3. Remove display work. Disable image rendering while retaining acquisition and logging. If host intervals improve but camera intervals do not change, the display path was affecting delivery or observation.
4. Reduce application work. Temporarily remove image processing and synchronous per-frame disk writes. Keep lightweight metadata capture, then save it outside the acquisition callback or receive loop.
5. Inspect identifiers and status counters. Correlate rate changes with missing identifiers, incomplete images, queue growth or documented stream errors.
6. Separate clock transitions. Recalculate only within stable timestamp segments. Investigate synchronization changes independently of viewer-rate fluctuations.

Use a monotonic elapsed-time clock for host intervals, not processor usage time. The distinction is explained in CPU time versus wall-clock benchmarking.

If the viewer’s estimator is undocumented, label it as a viewer-reported rate rather than claiming it measures exposure cadence. Escalate with the raw timing record and exact measurement definitions, not screenshots alone.

7. Verify timing capabilities before choosing hardware

Do not replace a camera or controller simply because two rate indicators disagree. First establish whether the existing system exposes the timestamp event, units, identifiers and status information required for the measurement.

When evaluating area scan cameras, use the camera finder to narrow interface and imaging requirements. Then verify timing features in the candidate’s manufacturer documentation; interface type and resolution do not establish timestamp semantics.

The LS-CMR-0166 camera is a catalog candidate for that evaluation, not a claim of any particular timestamp capability.

For a dedicated acquisition host, compare vision controllers against the required connections, software compatibility and logging workload. Processor specifications alone do not establish deterministic buffer delivery.

The MV-VC2140-128G40-1T vision controller is another catalog candidate to assess against those requirements.

Before ordering, request confirmation of timestamp access, counter semantics and supported synchronization behavior for the exact proposed configuration. Record your required observation duration and acceptable interval variation as application requirements, rather than assuming catalog hardware guarantees them.

8. Keep a repeatable acceptance checklist

A useful acceptance record contains enough information for another application to reproduce the calculation.

• Define the measured event. State whether the result concerns exposure, buffer delivery, processing or display.
• Record units and clock domain. Save the conversion factor and its documented source.
• Keep raw metadata. Include frame identifiers, camera timestamps, host receive timestamps and synchronization state where available.
• State the counting convention. Distinguish endpoint-based cadence from events counted inside a fixed window.
• Report variation as well as average. Include interval extremes and the observation duration.
• Account for missing frames. Report identifier gaps and incomplete-image indicators separately from cadence.
• Repeat under normal workload. A stripped-down test identifies causes; production workload establishes operating performance.

The usual answer—trusting the longer average—is wrong when that average hides pauses, missed images or clock discontinuities. Accept a timing result only when its event definition, clock behavior and frame accounting support the conclusion.

For a new acquisition station, start with the camera configuration step. For an existing timing discrepancy, send the measurement definitions and a short raw timestamp log through application support before changing hardware.