Time Synchronization, Latency and Delayed Measurements

Sensor timestamps, master spacecraft time, clock offset and drift, PPS and hardware synchronization, camera and LiDAR timing, measurement latency, delayed and out-of-sequence measurements, rewind–update–replay processing, timing uncertainty, timing calibration, RPO timing requirements, and verification.

4.2.14 Time Synchronization, Latency and Delayed Measurements

Accurate spacecraft navigation does not depend only on what a sensor measures.

It also depends on when that measurement was physically valid.

A measurement may be numerically accurate, correctly calibrated, and expressed in the correct coordinate frame, but if it is fused at the wrong time, the estimator can still generate a significant state error.

This becomes especially important in spacecraft systems because several independent timing effects may exist simultaneously:

The basic timing problem can be written as

\[ \boxed{ t_{\text{arrival}} = t_{\text{measurement}} + \tau } \]

where

\[ \boxed{ \tau = \tau_{\text{sensor}} + \tau_{\text{processing}} + \tau_{\text{communication}} + \tau_{\text{buffering}}. } \]

The navigation estimator must therefore distinguish between

\[ \boxed{ \text{When the Physical Quantity Was Observed} } \]

and

\[ \boxed{ \text{When the Measurement Became Available to the Filter}. } \]

The central timing principle is

\[ \boxed{ \text{A Measurement Must Be Fused With the State at the Epoch to Which That Measurement Belongs}. } \]

4.2.14.1 Why Timing Matters in Sensor Fusion

Consider a spacecraft moving with velocity

\[ \mathbf v. \]

Suppose a position measurement is delayed by

\[ \Delta t. \]

During that delay, the spacecraft moves approximately

\[ \boxed{ \Delta \mathbf r \approx \mathbf v\Delta t. } \]

If the delayed measurement is incorrectly compared with the current position estimate, the filter sees an artificial residual.

Similarly, if the spacecraft rotates with angular velocity

\[ \boldsymbol\omega, \]

a timing error produces approximately

\[ \boxed{ \Delta\boldsymbol\theta \approx \boldsymbol\omega\Delta t. } \]

Therefore timing error becomes state error.

4.2.14.2 Measurement Time and Arrival Time

A measurement has at least two important times.

Measurement Time

\[ \boxed{ t_m } \]

This is when the physical quantity was actually observed.

Arrival Time

\[ \boxed{ t_a } \]

This is when the measurement becomes available to the estimator.

Generally,

\[ \boxed{ t_a \ge t_m. } \]

The difference is the latency:

\[ \boxed{ \tau = t_a-t_m. } \]

Why the distinction matters

Arrival time tells the software when a packet became available; measurement time tells the estimator which physical state the data actually constrains. Treating these as interchangeable creates temporal inconsistency.

4.2.14.3 Example: Camera Measurement Delay

Suppose an image is captured at

\[ \boxed{ t_m=10.000~\mathrm{s}. } \]

Feature extraction and pose estimation take

\[ 80~\mathrm{ms}. \]

The navigation computer receives the pose at

\[ \boxed{ t_a=10.080~\mathrm{s}. } \]

The estimated pose measurement still belongs to

\[ 10.000~\mathrm{s}, \]

not

\[ 10.080~\mathrm{s}. \]

Thus:

\[ \boxed{ \text{Processing Completion Time} \neq \text{Physical Measurement Time}. } \]

4.2.14.4 Sensor Timestamp

Every sensor measurement should ideally contain a timestamp:

\[ \boxed{ t_{\text{sensor}}. } \]

The timestamp should identify when the physical measurement was valid.

For simple sensors, this may approximately equal the sampling instant.

For complex sensors such as cameras and scanning LiDAR, defining the correct timestamp may require more care.

4.2.14.5 Timestamp Source

A timestamp may be generated by

The closer timestamp generation occurs to the physical measurement event, the more reliable the timestamp usually is.

4.2.14.6 Software Timestamping

Suppose the onboard software timestamps a measurement only after receiving a packet.

Then the timestamp includes unknown communication and processing delay.

Thus:

\[ \boxed{ t_{\text{software}} = t_m + \tau_{\text{unknown}}. } \]

Software timestamping may be adequate for slow systems but can be problematic during high-dynamics RPO.

4.2.14.7 Hardware Timestamping

Hardware timestamping assigns time as close as possible to the physical acquisition event.

Examples include

This reduces timing uncertainty significantly.

4.2.14.8 Master Spacecraft Time

A spacecraft may define one common onboard time base:

\[ \boxed{ t_{\text{SC}}. } \]

All sensor timestamps should ideally be correlated to this master time.

Then

\[ \boxed{ t_{\text{GNSS}}, t_{\text{IMU}}, t_{\text{camera}}, t_{\text{LiDAR}} \rightarrow t_{\text{SC}}. } \]

This greatly simplifies fusion.

4.2.14.9 Clock Offset

Suppose a sensor clock is

\[ t_s \]

and spacecraft master time is

\[ t_{\text{SC}}. \]

A constant offset may exist:

\[ \boxed{ b_t = t_s-t_{\text{SC}}. } \]

Then the corrected time is

\[ \boxed{ t_{\text{SC}} = t_s-b_t. } \]

If the offset is not corrected, all measurements from that sensor are shifted in time.

4.2.14.10 Clock Drift

Clock offset may not remain constant.

A sensor oscillator may run slightly faster or slower.

A simple clock model is

\[ \boxed{ t_s = (1+\epsilon)t_{\text{SC}} + b. } \]

Here,

Over time, even a small

\[ \epsilon \]

can produce significant timing error.

Clock-model interpretation

The affine clock model separates a fixed time bias from a clock-rate error. In practice, the offset can often be calibrated quickly, while drift must be monitored over time because it accumulates.

4.2.14.11 Clock-Skew Interpretation

If

\[ \epsilon>0, \]

the sensor clock runs faster than spacecraft time.

If

\[ \epsilon<0, \]

it runs slower.

Therefore:

\[ \boxed{ \text{Clock Offset} \rightarrow \text{Constant Timing Error} } \]

while

\[ \boxed{ \text{Clock Drift} \rightarrow \text{Timing Error That Grows With Time}. } \]

4.2.14.12 Example of Clock Drift

Suppose clock-rate error is

\[ 10~\mathrm{ppm}. \]

This corresponds to

\[ 10\times10^{-6}. \]

After

\[ 1000~\mathrm{s}, \]

the accumulated error is approximately

\[ \boxed{ 10^{-5} \times 1000 = 0.01~\mathrm{s}. } \]

Thus a 10 ppm oscillator can accumulate

\[ 10~\mathrm{ms} \]

of error in roughly 1000 seconds.

4.2.14.13 Timing Error During Fast Motion

Suppose relative velocity is

\[ v_{rel}=0.5~\mathrm{m/s} \]

and timing error is

\[ \Delta t=50~\mathrm{ms}. \]

Then

\[ \Delta r \approx v_{rel}\Delta t \]

gives

\[ \boxed{ \Delta r \approx 0.025~\mathrm{m}. } \]

That is

\[ 2.5~\mathrm{cm}. \]

For close-proximity navigation, this may be significant.

4.2.14.14 Timing Error During Fast Attitude Motion

Suppose spacecraft angular rate is

\[ 5^\circ/\mathrm{s} \]

and timestamp error is

\[ 100~\mathrm{ms}. \]

Then

\[ \Delta\theta \approx \omega\Delta t \]

gives

\[ \boxed{ \Delta\theta \approx 0.5^\circ. } \]

For precise attitude or docking operations, this may be unacceptable.

4.2.14.15 Pulse-Per-Second Synchronization

GNSS receivers often provide

\[ \boxed{ \text{PPS} } \]

or Pulse Per Second.

PPS provides a precise timing pulse aligned with GNSS time.

This can be used to synchronize

4.2.14.16 PPS and Measurement Timing

PPS does not itself contain the complete timestamp.

It identifies precise second boundaries.

A corresponding time message provides the actual time label.

Together:

\[ \boxed{ \text{PPS} + \text{Time Message} \rightarrow \text{Accurate Epoch Reference}. } \]

4.2.14.17 Hardware Trigger Synchronization

A common hardware trigger can synchronize sensor acquisition.

For example,

\[ \boxed{ \text{Trigger} \rightarrow \text{Camera Exposure} } \]

and simultaneously

\[ \boxed{ \text{Trigger} \rightarrow \text{LiDAR Acquisition}. } \]

This aligns the physical sensing events even if processing completes at different times.

4.2.14.18 Hardware Synchronization vs Software Synchronization

Hardware synchronization controls acquisition timing directly.

Software synchronization corrects timestamps after acquisition.

Thus:

\[ \boxed{ \text{Hardware Synchronization} \rightarrow \text{Reduce Timing Error at the Source} } \]

while

\[ \boxed{ \text{Software Synchronization} \rightarrow \text{Estimate and Compensate Timing Error}. } \]

Hardware synchronization is generally preferable when available.

Engineering preference

Hardware synchronization is generally preferred because it reduces timing uncertainty before estimation. Software synchronization remains important for converting residual offsets, variable latencies, or independent sensor clocks into one common mission time.

4.2.14.19 Camera Exposure Timing

A camera image is not necessarily instantaneous.

Suppose exposure begins at

\[ t_s \]

and ends at

\[ t_e. \]

A common effective timestamp is

\[ \boxed{ t_c = \frac{t_s+t_e}{2}. } \]

This approximates the image as representing the scene at exposure midpoint.

4.2.14.20 Long Camera Exposure

If exposure duration is

\[ T_e=t_e-t_s, \]

and the spacecraft rotates significantly during

\[ T_e, \]

the image may contain motion blur.

Thus timing uncertainty is not just a timestamp problem.

It can alter the measurement itself.

4.2.14.21 Rolling-Shutter Cameras

A rolling-shutter camera exposes different image rows at different times.

Therefore one image may correspond to many timestamps.

Conceptually:

\[ \boxed{ t_{\text{row}} = t_0 + k\Delta t_{\text{row}}. } \]

For rapidly moving spacecraft, rolling shutter can create geometric distortion.

A single image timestamp may be insufficient.

4.2.14.22 Global-Shutter Cameras

A global-shutter camera exposes all pixels approximately simultaneously.

Therefore the image is much easier to associate with one timestamp.

For high-dynamics RPO, global-shutter cameras are often attractive for this reason.

4.2.14.23 LiDAR Timing

LiDAR timing depends on measurement type.

A flash LiDAR may capture an entire scene nearly simultaneously.

A scanning LiDAR may generate individual points sequentially.

Therefore:

\[ \boxed{ \text{One LiDAR Scan} \neq \text{One Physical Time} } \]

for many scanning systems.

4.2.14.24 LiDAR Scan Deskewing

Suppose a LiDAR scan spans

\[ [t_s,t_e]. \]

If the spacecraft moves during this interval, the point cloud becomes distorted.

Deskewing transforms each point according to the estimated spacecraft state at its individual timestamp.

Conceptually:

\[ \boxed{ \mathbf p_i(t_i) \rightarrow \mathbf p_i(t_{\text{reference}}). } \]

Why LiDAR deskewing matters

If the spacecraft translates or rotates significantly during a scan, treating the whole point cloud as simultaneous distorts geometry. Deskewing maps each point to a common reference epoch before pose or range estimation.

4.2.14.25 IMU Timestamping

IMU measurements typically have short processing delay but high update rate.

Because IMU samples may arrive at

\[ 100\text{–}1000~\mathrm{Hz} \]

or higher, even small timestamp inconsistencies can accumulate in integration.

Each inertial sample should therefore use its actual

\[ \Delta t. \]

4.2.14.26 GNSS Timing

GNSS provides precise time and navigation measurements at known epochs.

However, the navigation message may arrive after the physical measurement epoch.

Therefore:

\[ \boxed{ \text{GNSS Measurement Epoch} \neq \text{Packet Reception Time}. } \]

The filter should use the GNSS measurement epoch.

4.2.14.27 Sensor Processing Latency

Let

\[ \tau_p \]

represent processing latency.

For simple sensors,

\[ \tau_p \]

may be negligible.

For camera-based pose estimation,

\[ \tau_p \]

may be tens or hundreds of milliseconds.

The latency may also vary depending on

4.2.14.28 Communication Latency

Measurements may be transmitted over

Communication introduces

\[ \boxed{ \tau_{\text{comm}}. } \]

For distributed spacecraft, communication latency can be especially significant.

4.2.14.29 Buffering Latency

Measurements may wait in a queue before processing.

Thus:

\[ \boxed{ \tau_{\text{buffer}} = t_{\text{dequeue}} - t_{\text{enqueue}}. } \]

Under heavy processor load, this latency may become variable.

4.2.14.30 Scheduling Latency

Real-time software may process navigation tasks according to a schedule.

A sensor event may occur at one time but the estimator may not execute until its scheduled task slot.

This creates

\[ \boxed{ \tau_{\text{sched}}. } \]

4.2.14.31 Total Latency

A more complete latency model is

\[ \boxed{ \tau_{\text{total}} = \tau_{\text{sensor}} + \tau_{\text{processing}} + \tau_{\text{communication}} + \tau_{\text{buffer}} + \tau_{\text{scheduler}}. } \]

Then

\[ \boxed{ t_a = t_m + \tau_{\text{total}}. } \]

4.2.14.32 Constant Latency

If latency is approximately constant,

\[ \boxed{ \tau=\tau_0, } \]

it may be calibrated and removed:

\[ \boxed{ t_m = t_a-\tau_0. } \]

Constant latency is easier to manage than variable latency.

4.2.14.33 Variable Latency

If latency changes from sample to sample:

\[ \boxed{ \tau_k = \tau_0 + \delta\tau_k. } \]

Then compensation requires either

Variable delay is more difficult than constant delay.

4.2.14.34 Latency Jitter

Latency jitter describes variations in delay.

Define

\[ \boxed{ \delta\tau_k = \tau_k-\bar\tau. } \]

Large jitter can make measurement arrival order unpredictable.

It can also produce out-of-sequence measurements.

4.2.14.35 Delayed Measurement

A measurement is delayed when it arrives after the estimator has already propagated beyond its measurement epoch.

Thus:

\[ \boxed{ t_m < t_{\text{filter}}. } \]

Example:

\[ t_m=5.0~\mathrm{s} \]

while current navigation time is

\[ t_{\text{filter}}=5.1~\mathrm{s}. \]

4.2.14.36 Why Directly Applying a Delayed Measurement Is Wrong

Suppose the estimator is currently at

\[ t_c. \]

A delayed measurement belongs to

\[ t_m

If we calculate

\[ r = z(t_m) - h( \hat x(t_c) ), \]

we compare states from different times.

Thus:

\[ \boxed{ \text{Old Measurement} - \text{Current Prediction} = \text{Artificial Residual}. } \]

Estimator interpretation

A delayed measurement is not necessarily bad data. The error arises when the measurement is compared with the wrong predicted state. If the state can be reconstructed at the measurement epoch, the delayed observation can still be valuable.

4.2.14.37 Correct Delayed-Measurement Principle

The proper conceptual procedure is:

\[ \boxed{ \text{Recover State at }t_m } \]

\[ \downarrow \]

\[ \boxed{ \text{Apply Measurement at }t_m } \]

\[ \downarrow \]

\[ \boxed{ \text{Repropagate to Current Time}. } \]

This preserves temporal consistency.

Core delayed-update logic

This three-step sequence is the foundation of rewind-and-replay implementations. The measurement first corrects the correct historical state, then its effect is propagated forward to the present.

4.2.14.38 State History Buffer

To process delayed measurements, the estimator may store past states:

\[ \boxed{ \hat x(t_k), P(t_k). } \]

A history buffer may contain

\[ \boxed{ \{ t_i, \hat x_i, P_i \}. } \]

For inertial navigation, it may also store IMU or control inputs needed for repropagation.

4.2.14.39 Required History Length

If maximum expected delay is

\[ \tau_{\max}, \]

the state-history buffer should cover at least

\[ \boxed{ T_{\text{history}} \ge \tau_{\max}. } \]

Additional margin is usually desirable.

4.2.14.40 History Buffer Memory Cost

Suppose state dimension is

\[ n. \]

Storing covariance requires approximately

\[ n^2 \]

elements per history entry.

Therefore long history buffers can consume substantial memory.

For high-dimensional filters, storage strategy matters.

4.2.14.41 Store State and Inputs

To repropagate correctly, the estimator may need

Thus history is not just

\[ x(t). \]

It may require the full sequence of inputs between the delayed measurement and the current time.

4.2.14.42 Propagation to Measurement Time

Suppose stored state exists at

\[ t_k \]

and delayed measurement belongs to

\[ t_m \]

with

\[ t_k

Propagate:

\[ \boxed{ \hat x(t_m)^- = f( \hat x(t_k)^+, t_m-t_k ). } \]

Likewise,

\[ \boxed{ P(t_m)^- = \Phi P(t_k)^+ \Phi^T + Q_d. } \]

4.2.14.43 Delayed Measurement Correction

At

\[ t_m, \]

compute innovation:

\[ \boxed{ r_m = z_m - h( \hat x(t_m)^- ). } \]

Then perform the ordinary measurement update.

For an EKF:

\[ \boxed{ K_m = P_m^-H_m^T \left( H_mP_m^-H_m^T+R_m \right)^{-1}. } \]

Then

\[ \boxed{ \hat x_m^+ = \hat x_m^- + K_mr_m. } \]

4.2.14.44 Covariance Correction at Measurement Time

The covariance is corrected at the same measurement epoch.

For example:

\[ \boxed{ P_m^+ = (I-K_mH_m) P_m^-. } \]

or using Joseph form:

\[ \boxed{ P_m^+ = (I-K_mH_m) P_m^- (I-K_mH_m)^T + K_mR_mK_m^T. } \]

4.2.14.45 Repropagation to Current Time

After correcting the state at

\[ t_m, \]

the estimator must replay all subsequent inputs.

Thus:

\[ \boxed{ \hat x(t_c) = \Phi_{m\rightarrow c} \hat x(t_m)^+ } \]

conceptually.

For nonlinear systems, repropagation uses the full nonlinear dynamics.

4.2.14.46 Repropagation Sequence

Suppose stored sequence is

\[ t_m

Then:

\[ \boxed{ x(t_m)^+ } \]

\[ \downarrow \]

\[ \boxed{ \text{Apply Input }u_1 } \]

\[ \downarrow \]

\[ \boxed{ x(t_1) } \]

\[ \downarrow \]

\[ \boxed{ \text{Apply Input }u_2 } \]

\[ \downarrow \]

\[ \boxed{ x(t_2) } \]

\[ \downarrow \]

\[ \boxed{ x(t_c). } \]

4.2.14.47 Why Repropagation Is Necessary

The delayed measurement changes the historical state.

Therefore every later predicted state derived from the old historical state is no longer correct.

Thus:

\[ \boxed{ \text{Past Correction} \rightarrow \text{Changes All Future Predictions}. } \]

That is why repropagation is required.

4.2.14.48 Repropagating Covariance

The same logic applies to uncertainty.

After correcting

\[ P(t_m), \]

all later covariance values must be recomputed using

\[ \boxed{ P_{k+1} = \Phi_kP_k\Phi_k^T+Q_k. } \]

Using the old current covariance after a delayed state correction would be inconsistent.

4.2.14.49 Replaying Later Measurements

Suppose another measurement had already been processed at

\[ t_2>t_m. \]

If the filter rewinds to

\[ t_m, \]

then the later measurement may need to be replayed as well.

Thus the history buffer may store

Why later measurements may need replay

Any later update was computed from a state trajectory that has now changed. Replaying later measurements keeps both state and covariance consistent with the corrected historical trajectory.

4.2.14.50 Rewind–Update–Replay

A common delayed-measurement architecture is

\[ \boxed{ \text{Rewind} } \]

\[ \downarrow \]

\[ \boxed{ \text{Update at Historical Time} } \]

\[ \downarrow \]

\[ \boxed{ \text{Replay Inputs and Later Measurements} } \]

\[ \downarrow \]

\[ \boxed{ \text{Recover Current State}. } \]

4.2.14.51 Computational Cost of Repropagation

If delay is large, many historical propagation steps may need to be repeated.

Thus computational cost grows approximately with

\[ \boxed{ \frac{\tau_{\text{delay}}} {\Delta t_{\text{propagation}}}. } \]

For high-rate IMU systems, even modest delays can require many replay steps.

4.2.14.52 Example

Suppose IMU rate is

\[ 200~\mathrm{Hz} \]

and camera delay is

\[ 150~\mathrm{ms}. \]

The number of IMU intervals that may need replay is approximately

\[ \boxed{ 0.15\times200 = 30. } \]

Thus one delayed camera update may require replaying around 30 inertial propagation steps.

4.2.14.53 Out-of-Sequence Measurement

An Out-of-Sequence Measurement (OOSM) is a measurement that arrives after one or more measurements with later timestamps have already been processed.

Suppose processing order is

\[ z(t_1) \]

then

\[ z(t_3) \]

then later

\[ z(t_2) \]

with

\[ t_1

Then

\[ z(t_2) \]

is an out-of-sequence measurement.

What makes OOSM special

An out-of-sequence measurement is more than ordinary latency because one or more later-time measurements have already been fused. Correct handling must preserve chronological information flow.

4.2.14.54 Why OOSM Is More Difficult

A simple delayed measurement may arrive after prediction only.

An OOSM may arrive after later sensor updates have already modified the state.

Therefore handling it correctly may require replaying not only dynamics but also later measurement updates.

4.2.14.55 OOSM Example

Consider:

\[ t_1: \text{GNSS} \]

\[ t_2: \text{Camera} \]

\[ t_3: \text{LiDAR}. \]

Suppose arrival order is

\[ \boxed{ GNSS \rightarrow LiDAR \rightarrow Camera. } \]

The camera update belongs between GNSS and LiDAR in time.

Proper reconstruction may require reprocessing the LiDAR update after the camera correction.

4.2.14.56 OOSM Handling Strategies

Possible strategies include

The best choice depends on

4.2.14.57 Rejecting Old Measurements

A simple strategy is:

\[ \boxed{ \Delta t_{\text{age}} > \Delta t_{\max} \Rightarrow \text{Reject Measurement}. } \]

This avoids computational complexity but discards potentially useful information.

4.2.14.58 When Rejection May Be Acceptable

Rejection may be reasonable when

4.2.14.59 When Rejection May Be Dangerous

Rejecting delayed measurements may be unacceptable when

4.2.14.60 Approximate Current-Time Update

One simplified method tries to transform an old measurement into an equivalent current measurement.

This may work for some simple dynamics.

However, the approximation can become inaccurate for

4.2.14.61 Fixed-Lag Smoothing

A fixed-lag smoother maintains a moving history window:

\[ \boxed{ [t-T_L,t]. } \]

Measurements arriving inside this window can update historical states.

Older states are finalized and removed.

When fixed-lag smoothing is attractive

A fixed-lag smoother is useful when delays are common but bounded. It avoids retaining the entire mission history while still allowing measurements to update recent past states.

4.2.14.62 Why Fixed-Lag Smoothing Is Useful

Fixed-lag smoothing provides a compromise between

\[ \boxed{ \text{Real-Time Filtering} } \]

and

\[ \boxed{ \text{Full Batch Smoothing}. } \]

It can handle moderate measurement delays while keeping memory and computation bounded.

4.2.14.63 Fixed-Lag Window

Let lag be

\[ T_L. \]

Then measurements are accepted for historical correction if

\[ \boxed{ t_m \ge t_{\text{current}}-T_L. } \]

Older measurements may be rejected.

4.2.14.64 Delay-Aware State Augmentation

Another method is to augment the state with delayed states.

For example,

\[ \boxed{ X_k = \begin{bmatrix} x_k\\ x_{k-1}\\ x_{k-2} \end{bmatrix}. } \]

Then a delayed measurement can directly update the relevant historical component.

However, state dimension grows substantially.

4.2.14.65 State Augmentation Cost

If original state dimension is

\[ n \]

and

\[ L \]

historical states are included, augmented dimension becomes approximately

\[ \boxed{ n(L+1). } \]

Covariance size then scales approximately as

\[ \boxed{ n^2(L+1)^2. } \]

Thus long delay windows can be computationally expensive.

4.2.14.66 Factor-Graph Interpretation

In a factor graph, each state exists at its own time node.

A delayed measurement can simply attach a new measurement factor to the historical state node corresponding to

\[ t_m. \]

Then optimization updates the affected states.

This is one reason factor-graph approaches are attractive for asynchronous sensor fusion.

4.2.14.67 Filtering vs Smoothing

Filtering estimates

\[ \boxed{ x_k | z_{1:k}. } \]

Smoothing may estimate past states using future measurements:

\[ \boxed{ x_j | z_{1:k}, \qquad j

Delayed measurements naturally introduce smoothing-like behavior because they provide new information about past states.

4.2.14.68 Time-Correlation Error

Suppose sensor time and master time are related by

\[ \boxed{ t_s = a t+b. } \]

Then calibration requires estimating

\[ a \]

and

\[ b. \]

This process is called time correlation.

4.2.14.69 Clock-Calibration Experiment

A simple timing calibration may record pairs:

\[ \boxed{ (t_{\text{sensor},i}, t_{\text{master},i}) } \]

and fit

\[ t_{\text{sensor}} = a t_{\text{master}} + b. \]

The estimated

\[ a,b \]

are then used to convert sensor time into master spacecraft time.

4.2.14.70 Online Clock-State Estimation

Timing offset itself may be included in the navigation state:

\[ \boxed{ x = \begin{bmatrix} x_{\text{nav}}\\ \delta t \end{bmatrix}. } \]

Then

\[ \delta t \]

can be estimated jointly with navigation states if the system is sufficiently observable.

4.2.14.71 Clock Drift as a State

A more complete timing model may include

\[ \boxed{ x_t = \begin{bmatrix} \delta t\\ \dot{\delta t} \end{bmatrix}. } \]

with dynamics

\[ \boxed{ \dot{\delta t} = \delta f } \]

and

\[ \boxed{ \dot{\delta f} = n_f. } \]

This resembles clock models used in GNSS navigation.

4.2.14.72 Timing-Error Observability

A timing offset is observable only if changing the measurement time produces a distinguishable measurement effect.

If the system is nearly static,

\[ \frac{\partial h}{\partial t} \approx0, \]

then timing error may be difficult to estimate.

During dynamic motion, timing offset becomes more observable.

Observability interpretation

Timing offset becomes observable only when shifting the measurement time changes the predicted measurement sufficiently. Nearly static motion provides little information about delay, whereas deliberate excitation can reveal it.

4.2.14.73 Motion Excites Timing Observability

Suppose position changes rapidly.

Then

\[ \boxed{ \frac{\partial r}{\partial t} = v. } \]

Large velocity increases sensitivity to time offset.

Similarly,

\[ \boxed{ \frac{\partial\theta}{\partial t} = \omega. } \]

Thus dynamic maneuvers can improve timing calibration.

4.2.14.74 But Motion Also Makes Timing Error More Dangerous

The same sensitivity that improves observability also increases navigation error if timing is wrong.

Thus:

\[ \boxed{ \text{High Dynamics} \rightarrow \text{Better Timing Observability} } \]

but also

\[ \boxed{ \text{High Dynamics} \rightarrow \text{Greater Sensitivity to Timing Error}. } \]

4.2.14.75 Sensor Latency Estimation

Persistent latency may be estimated by comparing sensor outputs with a reference.

One approach is to vary candidate delay

\[ \tau \]

and find the value that minimizes residuals:

\[ \boxed{ \tau^\star = \arg\min_\tau \sum_k \| z_k - h( x(t_k-\tau) ) \|^2. } \]

4.2.14.76 Cross-Correlation Timing Estimation

For correlated signals, timing offset can be estimated from cross-correlation.

For signals

\[ a(t) \]

and

\[ b(t), \]

estimate delay from

\[ \boxed{ R_{ab}(\tau) = \int a(t)b(t+\tau)\,dt. } \]

The peak identifies the likely time shift.

4.2.14.77 Gyro–Camera Time Calibration

A common calibration problem is synchronizing camera attitude motion with gyroscope angular rate.

Image-based orientation changes can be compared with integrated gyro rotation.

The delay producing the smallest disagreement estimates camera-to-IMU timing offset.

4.2.14.78 GNSS–IMU Time Calibration

GNSS velocity changes can be compared with accelerometer-integrated velocity.

Timing mismatch appears as phase shift between the two signals.

Dynamic maneuvers help reveal this offset.

4.2.14.79 LiDAR–Camera Time Calibration

For relative navigation, camera and LiDAR motion estimates can be compared over time.

A persistent shift between their predicted target motion may indicate timing misalignment.

4.2.14.80 Timing Error Can Mimic Lever-Arm Error

Suppose the spacecraft rotates.

A delayed measurement from an offset sensor location may look like an incorrect lever arm.

Thus timing and geometric calibration errors can become coupled.

This means:

\[ \boxed{ \text{Timing Calibration} \neq \text{Independent of Sensor Geometry}. } \]

Calibration coupling

Timing, lever arm, and boresight errors can generate similar residual signatures during motion. These parameters should therefore be calibrated with sufficiently rich maneuvers and not tuned independently without checking cross-coupling.

4.2.14.81 Timing Error Can Mimic Boresight Error

Likewise, delayed camera measurements during rotation may appear as a constant angular misalignment.

Therefore:

\[ \boxed{ \text{Apparent Boresight Error} } \]

may partly arise from

\[ \boxed{ \text{Timestamp Error}. } \]

Timing should be validated before final boresight calibration.

4.2.14.82 Timing Error Can Mimic Sensor Bias

Persistent delay can create systematic residuals.

The estimator may incorrectly absorb these residuals into

Thus badly synchronized data can corrupt bias estimation.

4.2.14.83 Frame Transformation at Correct Time

Suppose camera measurement requires transformation

\[ C_{IC}(t_m). \]

Using

\[ C_{IC}(t_a) \]

instead may produce a false line-of-sight residual.

Therefore:

\[ \boxed{ \text{Coordinate Transformation Must Use the Measurement Epoch}. } \]

4.2.14.84 Lever Arm at Measurement Time

For a sensor located at body-fixed lever arm

\[ r_{S/CG}^B, \]

its inertial position is

\[ \boxed{ r_S^I(t) = r_{CG}^I(t) + C_{IB}(t) r_{S/CG}^B. } \]

Therefore both spacecraft position and attitude must correspond to the sensor measurement time.

4.2.14.85 Delayed Thruster Telemetry

Actuation data can also be delayed.

Suppose thruster actually fires at

\[ t_b \]

but telemetry reports the event later.

Navigation propagation should still include thrust at

\[ t_b. \]

Otherwise the estimator may incorrectly attribute the resulting motion to sensor error.

4.2.14.86 Command Time vs Execution Time

A control command may be generated at

\[ t_c \]

but actuator response begins at

\[ t_a=t_c+\tau_{\text{act}}. \]

The navigation model should ideally use execution time rather than command-generation time.

4.2.14.87 Valve Latency Example

For a thruster valve:

\[ \boxed{ t_{\text{thrust start}} = t_{\text{command}} + \tau_{\text{valve}}. } \]

If

\[ \tau_{\text{valve}} \]

is not represented, propagation during burns becomes slightly phase shifted.

This can matter during precision RPO.

4.2.14.88 Sensor and Actuator Timing Together

Navigation accuracy depends on both

\[ \boxed{ \text{When Sensors Observe Motion} } \]

and

\[ \boxed{ \text{When Actuators Actually Change Motion}. } \]

Thus sensor synchronization and actuator timing should be considered together in high-fidelity GNC simulation.

4.2.14.89 Delayed Measurement and RPO

During RPO, delayed data may occur from

A delayed relative-state measurement can significantly affect final approach if relative motion is changing rapidly.

4.2.14.90 Far-Range RPO Timing

At far range, relative motion is typically slower and navigation tolerances may be looser.

Moderate measurement latency may therefore be acceptable.

However, long communication delays can still matter.

4.2.14.91 Mid-Range RPO Timing

As the chaser approaches, camera and relative GNSS measurements become increasingly important.

Timing inconsistencies can create

4.2.14.92 Close-Range RPO Timing

Near the target, centimetre-level errors may matter.

Suppose

\[ v_{rel}=0.1~\mathrm{m/s}. \]

A delay of

\[ 100~\mathrm{ms} \]

corresponds to approximately

\[ \boxed{ 1~\mathrm{cm} } \]

of position mismatch.

This may already be significant for capture logic.

4.2.14.93 Capture-Phase Timing

Capture readiness may require

\[ \boxed{ \|r_{rel}\| < r_c } \]

\[ \boxed{ \|v_{rel}\| < v_c } \]

\[ \boxed{ \|\theta_{rel}\| < \theta_c } \]

\[ \boxed{ \|\omega_{rel}\| < \omega_c. } \]

All of these quantities must refer to the same epoch.

4.2.14.94 Timing and Capture Dwell

Suppose capture conditions must hold for

\[ T_d. \]

The navigation system should ensure each sample used in the dwell logic corresponds to a valid synchronized state.

Otherwise stale data can create a false dwell condition.

4.2.14.95 Navigation Age Requirement

A practical safety requirement may be

\[ \boxed{ t_{\text{current}} - t_{\text{last valid update}} < T_{\max}. } \]

If the latest absolute navigation information is too old, approach may be inhibited.

4.2.14.96 Latency-Aware Guidance

Guidance may receive

\[ \hat x(t_c) \]

that has already been propagated to current time.

This is preferable to giving guidance an old measurement directly.

Thus:

\[ \boxed{ \text{Delayed Measurement} \rightarrow \text{Correct Historical Update} \rightarrow \text{Current Navigation State} \rightarrow \text{Guidance}. } \]

4.2.14.97 Do Not Feed Delayed Raw State Directly to Control

A controller should generally not act directly on a delayed sensor state.

For example:

\[ \boxed{ r_{\text{camera}}(t_m) } \]

should not be used as though it were

\[ r(t_c). \]

The estimator should first reconcile timing and propagate to current time.

4.2.14.98 Latency Compensation

For simple systems, one may predict measurement forward:

\[ \boxed{ \hat x(t_a) \approx f( z(t_m), t_a-t_m ). } \]

However, estimator-based delay correction is generally more rigorous because it also propagates uncertainty.

4.2.14.99 Timestamp Uncertainty

A timestamp itself may have uncertainty:

\[ \boxed{ t_m = \bar t_m + \delta t. } \]

Then

\[ \delta t \]

acts like an additional uncertainty source.

4.2.14.100 Converting Timing Uncertainty into Measurement Uncertainty

For small timing error,

\[ z(t+\delta t) \approx z(t) + \dot z(t)\delta t. \]

Therefore timing uncertainty contributes approximately

\[ \boxed{ R_t = \dot z \sigma_t^2 \dot z^T. } \]

Then effective measurement covariance may be approximated as

\[ \boxed{ R_{\text{eff}} = R_{\text{sensor}} + R_t. } \]

Why timing can be represented as covariance

For small timestamp uncertainty, the measurement changes approximately linearly with time. This lets timing uncertainty be mapped into an equivalent measurement covariance contribution using the local measurement time derivative.

4.2.14.101 Physical Meaning of Timing Covariance

If the measured quantity changes rapidly,

\[ \|\dot z\| \]

is large.

Then a small

\[ \sigma_t \]

creates large additional measurement uncertainty.

If the system is nearly static,

\[ \dot z\approx0, \]

timing uncertainty matters much less.

4.2.14.102 Timing Uncertainty in RPO Position

For position measurement,

\[ \dot r=v. \]

Thus timing-induced covariance can be approximated by

\[ \boxed{ R_t \approx v\,\sigma_t^2\,v^T. } \]

This shows directly that higher relative speed increases sensitivity to timing uncertainty.

4.2.14.103 Timing Uncertainty in Attitude

For small attitude motion,

\[ \dot\theta\approx\omega. \]

Then approximately

\[ \boxed{ \sigma_\theta \approx |\omega|\sigma_t. } \]

Thus high angular rate magnifies timestamp uncertainty.

4.2.14.104 Time Offset as a Calibration Parameter

A sensor model may explicitly include delay:

\[ \boxed{ z_k = h( x(t_k-\tau) ) + v_k. } \]

Then

\[ \tau \]

may be estimated offline or online.

4.2.14.105 Measurement Jacobian with Respect to Delay

For small delay uncertainty,

\[ h(x(t-\tau)) \]

can be linearized with respect to

\[ \tau. \]

Approximately,

\[ \boxed{ \frac{\partial h}{\partial\tau} = - \frac{\partial h}{\partial x} \dot x. } \]

This can be used when timing offset is included as a filter state.

4.2.14.106 Delay Estimation Requires Excitation

If

\[ \dot x\approx0, \]

then

\[ \frac{\partial h}{\partial\tau} \approx0. \]

The estimator cannot distinguish delay from no delay.

Therefore timing calibration requires sufficient dynamic excitation.

4.2.14.107 Calibration Maneuvers

Timing calibration may use controlled motion such as

The goal is to create clear temporal signatures in multiple sensors.

4.2.14.108 Time Synchronization in Distributed Spacecraft

For multiple spacecraft,

\[ t_A \neq t_B \]

unless clocks are synchronized.

Relative measurements exchanged between vehicles therefore require time correlation.

This becomes especially important for

4.2.14.109 Communication Propagation Delay

Between spacecraft, radio signals require finite propagation time.

For separation

\[ d, \]

electromagnetic propagation delay is approximately

\[ \boxed{ \tau_{\text{prop}} = \frac{d}{c}. } \]

For close RPO this may be small, but for long-distance cooperative navigation it can matter.

4.2.14.110 One-Way vs Two-Way Ranging

One-way ranging requires good clock synchronization.

Two-way ranging can reduce dependence on absolute clock offset because round-trip timing is measured.

However, processing turnaround delay must still be known.

4.2.14.111 Timestamp Wraparound

Digital timestamps may eventually overflow or wrap.

For example, a finite-width counter may return from its maximum value to zero.

Navigation software must handle this explicitly.

Otherwise

\[ \Delta t \]

can become incorrect.

4.2.14.112 Timestamp Resolution

Timestamp resolution may be

\[ 1~\mathrm{ms}, \]

\[ 1~\mu\mathrm{s}, \]

or another value.

Quantization introduces timing uncertainty.

If timestamp resolution is

\[ \Delta t_q, \]

quantization error is approximately within

\[ \pm\frac{\Delta t_q}{2}. \]

4.2.14.113 Timing Precision vs Accuracy

Timing precision describes repeatability or resolution.

Timing accuracy describes closeness to true time.

A sensor can have

Both matter for sensor fusion.

4.2.14.114 Latency Precision vs Latency Mean

A sensor may have average latency

\[ \bar\tau \]

and latency standard deviation

\[ \sigma_\tau. \]

A large constant latency can often be compensated.

A smaller but highly variable latency may be more difficult to correct.

4.2.14.115 Timing Budget

A timing budget may allocate allowable error among components:

\[ \boxed{ \sigma_t^2 = \sigma_{\text{clock}}^2 + \sigma_{\text{trigger}}^2 + \sigma_{\text{processing}}^2 + \sigma_{\text{communication}}^2. } \]

This helps derive sensor and interface timing requirements.

Requirement-flow interpretation

A timing budget is most useful when it allocates a total navigation timing allowance among hardware clock error, triggering, processing, and communication. This makes subsystem timing requirements traceable to mission-level GNC performance.

4.2.14.116 Deriving Timing Requirement from Position Requirement

Suppose allowable timing-induced position error is

\[ \Delta r_{\max}. \]

Given maximum relative velocity

\[ v_{\max}, \]

a simple requirement is

\[ \boxed{ \Delta t_{\max} \le \frac{ \Delta r_{\max} }{ v_{\max} }. } \]

4.2.14.117 Deriving Timing Requirement from Attitude Requirement

Suppose allowable angular error is

\[ \Delta\theta_{\max}. \]

Given maximum angular rate

\[ \omega_{\max}, \]

require

\[ \boxed{ \Delta t_{\max} \le \frac{ \Delta\theta_{\max} }{ \omega_{\max} }. } \]

4.2.14.118 RPO Example for Timing Requirement

Suppose maximum acceptable timing-induced position error is

\[ 1~\mathrm{cm} \]

and maximum relative speed is

\[ 0.2~\mathrm{m/s}. \]

Then

\[ \Delta t_{\max} \le \frac{0.01}{0.2} \]

so

\[ \boxed{ \Delta t_{\max} \le 50~\mathrm{ms}. } \]

This provides a direct engineering timing requirement.

4.2.14.119 Attitude Example

Suppose allowable timing-induced attitude error is

\[ 0.1^\circ \]

and maximum slew rate is

\[ 2^\circ/\mathrm{s}. \]

Then

\[ \boxed{ \Delta t_{\max} \le 0.05~\mathrm{s} = 50~\mathrm{ms}. } \]

4.2.14.120 Timing Requirements Should Be Mission-Phase Dependent

Far from the target:

\[ \boxed{ \Delta t_{\max,\text{far}} } \]

may be relatively large.

Near capture:

\[ \boxed{ \Delta t_{\max,\text{capture}} } \]

should generally be much smaller.

Thus:

\[ \boxed{ \Delta t_{\max} = \Delta t_{\max}( \text{mission phase} ). } \]

4.2.14.121 Measurement Latency Metadata

A measurement packet may include

This allows the estimator and diagnostics software to distinguish where delay occurs.

4.2.14.122 Recommended Measurement Packet

A robust packet could conceptually contain

\[ \boxed{ \text{MeasurementPacket} = \{ t_m, t_a, \text{sensorID}, z, R, \text{valid}, N \}. } \]

Additional timing metadata can be included when necessary.

4.2.14.123 Timing Health Flag

A measurement should have a timing health condition.

For example:

\[ \boxed{ \text{timeValid} = 1 } \]

only if

A numerically good measurement with invalid timing should not automatically be fused.

Timing health is separate from sensor health

A sensor can be physically healthy and still provide unusable data if its timestamp is missing, stale, unsynchronized, or ambiguous. Timing validity should therefore be carried explicitly with the measurement.

4.2.14.124 Maximum Delay Gate

A practical system may use

\[ \boxed{ \tau_{\text{delay}} < \tau_{\max}. } \]

If the delay exceeds this limit, the measurement may be

4.2.14.125 Delay Gate Should Depend on Sensor Value

Different sensors may justify different delay limits.

A high-accuracy but rare absolute sensor may remain useful even when moderately delayed.

A low-value high-rate sensor may be discarded if stale.

Thus delay policy can be sensor specific.

4.2.14.126 Delay Gate Should Depend on Dynamics

If relative motion is slow,

\[ \tau_{\max} \]

may be larger.

If motion is fast,

\[ \tau_{\max} \]

should be smaller.

Therefore:

\[ \boxed{ \tau_{\max} = f( \text{Sensor}, \text{Dynamics}, \text{Mission Phase} ). } \]

4.2.14.127 Timing and Measurement Validation

Before performing a measurement update, verify

\[ \boxed{ \text{Measurement Value Valid} } \]

and

\[ \boxed{ \text{Timestamp Valid}. } \]

Both are required.

This provides the connection to the next topic: measurement validation and innovation gating.

4.2.14.128 Innovation Can Reveal Timing Error

Suppose the sensor itself is accurate but delayed.

The innovation may become systematically correlated with motion.

For example, position residual may approximate

\[ \boxed{ r \approx v\Delta t. } \]

Thus residual patterns can reveal timing problems.

4.2.14.129 Residual Sign During Delay

If a target moves steadily in one direction, a delayed measurement may consistently lag the predicted state.

Residual sign can therefore remain correlated with velocity direction.

This is a useful diagnostic signature.

4.2.14.130 Residual vs Angular Rate

For attitude measurements, timing error may create residual magnitude proportional to angular rate:

\[ \boxed{ \|r_\theta\| \propto \|\omega\| |\Delta t|. } \]

Plotting attitude residual against angular rate can help identify delay.

4.2.14.131 Timing Calibration from Residual Minimization

Suppose residual is

\[ r(\tau) = z - h( x(t-\tau) ). \]

One can estimate

\[ \boxed{ \tau^\star = \arg\min_\tau r(\tau)^TR^{-1}r(\tau). } \]

This directly connects timing calibration with innovation statistics.

4.2.14.132 Time Synchronization and NIS

Incorrect timing can increase

\[ \boxed{ NIS = r^TS^{-1}r. } \]

Thus repeated NIS failures during high dynamics may indicate synchronization problems rather than a purely statistical tuning issue.

4.2.14.133 Do Not Fix Timing Error Only by Increasing R

One might increase measurement covariance

\[ R \]

to reduce the apparent impact of timing-induced residuals.

This may hide the problem but does not correct the timestamp.

Therefore:

\[ \boxed{ \text{Wrong Timing} \neq \text{Just More Measurement Noise}. } \]

Correct synchronization should be addressed first.

Why covariance inflation is not a true fix

Increasing R may reduce the filter's sensitivity to a bad timestamp, but it does not restore temporal consistency. This can mask root-cause timing errors and reduce the value of an otherwise accurate sensor.

4.2.14.134 Do Not Absorb Timing Error into Bias States

Likewise, increasing bias process noise may let the estimator absorb timing errors.

This can produce apparently smooth results while corrupting physical bias estimates.

Timing must therefore be treated explicitly whenever significant.

4.2.14.135 Simulation of Latency

A realistic simulation should generate a measurement at

\[ t_m \]

but deliver it at

\[ \boxed{ t_a = t_m+\tau. } \]

The estimator should therefore receive measurement packets according to arrival time while using measurement time for fusion.

4.2.14.136 Simulation of Variable Delay

Delay may be modelled as

\[ \boxed{ \tau_k = \bar\tau + \delta\tau_k } \]

where

\[ \delta\tau_k \]

is random jitter.

For example,

\[ \delta\tau_k \sim \mathcal N( 0,\sigma_\tau^2 ). \]

4.2.14.137 Simulation of Packet Reordering

If latency is random, measurement arrival order may differ from measurement-time order.

Simulation should therefore allow

\[ t_{a,2} < t_{a,1} \]

even when

\[ t_{m,1} < t_{m,2}. \]

This tests true out-of-sequence processing.

4.2.14.138 Simulation of Clock Offset

Sensor timestamp may be generated as

\[ \boxed{ t_s = t_{\text{truth}} + b. } \]

The estimator then applies calibration to recover common time.

4.2.14.139 Simulation of Clock Drift

A drifting clock may be simulated using

\[ \boxed{ t_s = (1+\epsilon)t_{\text{truth}} + b. } \]

This is useful for long-duration tests.

4.2.14.140 Simulation of Timestamp Quantization

If timestamp resolution is

\[ \Delta t_q, \]

one may simulate

\[ \boxed{ t_s = \operatorname{round} \left( \frac{t}{\Delta t_q} \right) \Delta t_q. } \]

This tests sensitivity to finite timestamp resolution.

4.2.14.141 Monte Carlo Timing Analysis

Timing-related Monte Carlo parameters may include

4.2.14.142 Timing Monte Carlo Outputs

Evaluate

\[ \boxed{ \text{Position RMSE} } \]

\[ \boxed{ \text{Velocity RMSE} } \]

\[ \boxed{ \text{Attitude RMSE} } \]

\[ \boxed{ \text{NIS} } \]

\[ \boxed{ \text{NEES} } \]

\[ \boxed{ \text{Capture Success Rate} } \]

\[ \boxed{ \text{Timing-Rejection Rate}. } \]

4.2.14.143 Timing Sensitivity Sweep

A useful deterministic sweep is

\[ \boxed{ \tau = 0, 10, 20, 50, 100, 200~\mathrm{ms}. } \]

Plot navigation error versus delay.

This directly identifies allowable timing margins.

4.2.14.144 Verification Strategy

Time synchronization should be verified progressively.

4.2.14.144.1 Zero-Latency Baseline

Set

\[ \tau=0. \]

Verify nominal estimator performance.

4.2.14.144.2 Constant-Latency Test

Introduce known fixed delay.

Verify compensation recovers baseline behavior.

4.2.14.144.3 Variable-Latency Test

Add delay jitter.

Verify timestamps are still handled correctly.

4.2.14.144.4 Clock-Offset Test

Introduce known

\[ b. \]

Verify time-correlation compensation.

4.2.14.144.5 Clock-Drift Test

Introduce nonzero

\[ \epsilon. \]

Verify long-duration synchronization.

4.2.14.144.6 Delayed-Measurement Test

Deliver a measurement late.

Verify rewind–update–repropagate behavior.

4.2.14.144.7 OOSM Test

Send packets in incorrect arrival order.

Verify chronological reconstruction.

4.2.14.144.8 Packet-Loss Test

Drop measurements.

Verify navigation remains stable.

4.2.14.144.9 High-Dynamics Test

Perform fast slew or translation.

Verify timing sensitivity.

4.2.14.144.10 Sensor-Handover Timing Test

Transition among GNSS, camera, and LiDAR.

Verify time alignment across sensor changes.

Verification philosophy

Timing validation should progress from zero-delay and fixed-delay tests toward jitter, drift, out-of-sequence delivery, and multi-sensor handover. This isolates defects and prevents timing bugs from being confused with estimator-model errors.

4.2.14.145 Timing Verification with Truth Data

In simulation, truth state

\[ x_{\text{truth}}(t) \]

is available.

For every sensor packet, compare measurement prediction against truth at

\[ \boxed{ t_m } \]

rather than

\[ t_a. \]

This is one of the simplest ways to detect timestamp mistakes.

4.2.14.146 HIL Timing Verification

Hardware-in-the-loop testing should measure actual end-to-end latency.

Use known trigger signals and record

This identifies latency contributions across the complete hardware chain.

4.2.14.147 Measuring End-to-End Latency

A timing test may measure

\[ \boxed{ \tau_{\text{E2E}} = t_{\text{filter receive}} - t_{\text{physical acquisition}}. } \]

Repeat over many samples to estimate

\[ \bar\tau_{\text{E2E}} \]

and

\[ \sigma_\tau. \]

4.2.14.148 Logging Requirements

A good timing log should contain

Without these logs, debugging timing issues becomes difficult.

4.2.14.149 Timing Diagnostic Plots

Useful plots include

\[ \boxed{ \tau_k \text{ vs time} } \]

\[ \boxed{ r_k \text{ vs }\tau_k } \]

\[ \boxed{ r_k \text{ vs }\omega_k } \]

\[ \boxed{ r_k \text{ vs }v_k } \]

\[ \boxed{ NIS \text{ vs delay}. } \]

These plots can reveal systematic timing problems.

4.2.14.150 Timing and Sensor Health

A sensor may be physically healthy but timing-invalid.

Therefore sensor health should ideally distinguish

\[ \boxed{ \text{Measurement Health} } \]

from

\[ \boxed{ \text{Timing Health}. } \]

Both may be required before fusion.

4.2.14.151 Example Health Logic

A measurement may be accepted only if

\[ \boxed{ \text{sensorValid} = 1 } \]

and

\[ \boxed{ \text{timeValid} = 1 } \]

and

\[ \boxed{ \text{innovationValid} = 1. } \]

Thus:

\[ \boxed{ \text{Use Measurement} = \text{Sensor Health} \land \text{Timing Health} \land \text{Statistical Validity}. } \]

4.2.14.152 Delay-Aware Sensor Selection

Suppose two sensors measure the same quantity.

Sensor A is more accurate but delayed.

Sensor B is less accurate but current.

The navigation system may need to trade

\[ \boxed{ \text{Measurement Accuracy} } \]

against

\[ \boxed{ \text{Measurement Freshness}. } \]

4.2.14.153 Information Freshness

A measurement contains less operational value as it becomes stale.

This does not mean the historical information is statistically worthless.

It means more computation is required to correctly propagate that information to the current epoch.

4.2.14.154 Timing and Computational Architecture

Delayed-measurement handling may require

Thus timing is not just a sensor problem.

It directly affects software architecture.

4.2.14.155 Real-Time Timing Architecture

A robust architecture may be:

\[ \boxed{ \text{Sensor Acquisition} } \]

\[ \downarrow \]

\[ \boxed{ \text{Hardware Timestamp} } \]

\[ \downarrow \]

\[ \boxed{ \text{Clock Correlation} } \]

\[ \downarrow \]

\[ \boxed{ \text{Measurement Buffer} } \]

\[ \downarrow \]

\[ \boxed{ \text{Timestamp Validation} } \]

\[ \downarrow \]

\[ \boxed{ \text{Historical-State Lookup} } \]

\[ \downarrow \]

\[ \boxed{ \text{Update at Measurement Epoch} } \]

\[ \downarrow \]

\[ \boxed{ \text{Repropagate to Current Time}. } \]

4.2.14.156 Timing Manager

A dedicated timing manager can provide

This keeps timing logic separate from filter equations.

4.2.14.157 Estimator Should Not Guess Timestamps

If timestamp information is missing, the estimator should not silently assume

\[ t_m=t_a \]

unless that assumption is explicitly validated.

Unknown timing uncertainty should be treated as an actual system limitation.

4.2.14.158 Missing Timestamp Policy

Possible policies include

The correct choice depends on mission safety requirements.

4.2.14.159 Delayed Measurement and Covariance Consistency

A delayed measurement can reduce past covariance.

After repropagation, current covariance should also change accordingly.

Therefore both

\[ \boxed{ x } \]

and

\[ \boxed{ P } \]

must be replayed consistently.

4.2.14.160 Cross-Correlation Created by Historical Updates

If several delayed measurements update overlapping historical intervals, correlations can become complex.

This is one reason smoothing and factor-graph formulations may become attractive for heavily asynchronous systems.

4.2.14.161 Filter Approximation vs Smoother

For small delays, rewind and replay inside an EKF may be sufficient.

For frequent long delays or many out-of-sequence measurements, fixed-lag smoothing or factor graphs may provide a cleaner solution.

Thus architecture depends on delay structure.

4.2.14.162 Computational Trade

Increasing history length improves ability to accept delayed data but increases

Therefore:

\[ \boxed{ \text{Delay Tolerance} \leftrightarrow \text{Computational Cost}. } \]

4.2.14.163 Timing Requirements Should Come from Navigation Requirements

Timing requirements should not be selected arbitrarily.

Instead derive them from

This connects sensor interface requirements directly to GNC performance.

4.2.14.164 RPO Timing Requirement Flow

A useful design flow is:

\[ \boxed{ \text{Capture Position Requirement} } \]

\[ \downarrow \]

\[ \boxed{ \text{Maximum Relative Speed} } \]

\[ \downarrow \]

\[ \boxed{ \text{Allowable Timestamp Error}. } \]

Likewise:

\[ \boxed{ \text{Capture Attitude Requirement} } \]

\[ \downarrow \]

\[ \boxed{ \text{Maximum Angular Rate} } \]

\[ \downarrow \]

\[ \boxed{ \text{Allowable Timing Error}. } \]

4.2.14.165 Timing During Final Approach

During final approach, the estimator may use

\[ \boxed{ \text{Camera} + \text{LiDAR} + \text{IMU} } \]

with each sensor operating at different times.

The navigation state used by the controller should be propagated to a single common current epoch after all relevant delayed updates.

4.2.14.166 Timing During Robotics Handover

For robotics handover, relative

\[ r, v, q,\omega \]

may come from multiple sensor paths.

All must correspond to one timestamp before evaluating capture-ready logic.

Thus:

\[ \boxed{ \text{Synchronized State} \rightarrow \text{Capture-Ready Decision}. } \]

Why synchronization matters for robotics handover

Relative position, velocity, attitude, and angular rate may come from different sensing paths. Capture-ready logic is physically meaningful only when all four describe the same epoch.

4.2.14.167 Timing and Abort Logic

An abort decision should not rely on stale navigation information.

If state age exceeds a threshold:

\[ \boxed{ \Delta t_{\text{nav}} > \Delta t_{\text{safe}} } \]

the system may

Timing therefore becomes a safety variable.

4.2.14.168 Timing as a GNC Interface Requirement

Navigation should provide guidance with

\[ \boxed{ \hat x } \]

\[ \boxed{ P } \]

\[ \boxed{ t_{\text{state}} } \]

\[ \boxed{ \text{health}. } \]

Guidance should never need to assume the age of the navigation state.

4.2.14.169 Common Implementation Errors

Typical timing errors include:

4.2.14.170 Time Synchronization in One Diagram

The complete timing problem can be summarized as

\[ \boxed{ \text{Physical Sensor Event at }t_m } \]

\[ \downarrow \]

\[ \boxed{ \text{Timestamp} } \]

\[ \downarrow \]

\[ \boxed{ \text{Sensor Processing} } \]

\[ \downarrow \]

\[ \boxed{ \text{Communication} } \]

\[ \downarrow \]

\[ \boxed{ \text{Measurement Arrival at }t_a } \]

with

\[ \boxed{ t_a=t_m+\tau. } \]

The estimator then performs

\[ \boxed{ \text{Find State at }t_m } \]

\[ \downarrow \]

\[ \boxed{ \text{Apply Measurement Update at }t_m } \]

\[ \downarrow \]

\[ \boxed{ \text{Replay Inputs / Later Measurements} } \]

\[ \downarrow \]

\[ \boxed{ \text{Return to Current State at }t_c. } \]

4.2.14.171 Key Equations at a Glance

Measurement Latency

\[ \boxed{ \tau = t_a-t_m. } \]

Total Latency

\[ \boxed{ \tau = \tau_{\text{sensor}} + \tau_{\text{processing}} + \tau_{\text{communication}} + \tau_{\text{buffering}}. } \]

Clock Model

\[ \boxed{ t_s = (1+\epsilon)t+b. } \]

Timing-Induced Position Error

\[ \boxed{ \Delta r \approx v\Delta t. } \]

Timing-Induced Attitude Error

\[ \boxed{ \Delta\theta \approx \omega\Delta t. } \]

Propagation to Measurement Time

\[ \boxed{ x(t_m) = f( x(t_k), t_m-t_k ). } \]

Covariance Propagation

\[ \boxed{ P(t_m) = \Phi P(t_k) \Phi^T + Q_d. } \]

Delayed Innovation

\[ \boxed{ r_m = z_m - h( x(t_m) ). } \]

Historical Measurement Update

\[ \boxed{ x_m^+ = x_m^- + K_mr_m. } \]

Timing-Uncertainty Contribution

\[ \boxed{ R_t \approx \dot z \sigma_t^2 \dot z^T. } \]

Effective Measurement Covariance

\[ \boxed{ R_{\text{eff}} = R_{\text{sensor}} + R_t. } \]

Timing Requirement from Position

\[ \boxed{ \Delta t_{\max} \le \frac{ \Delta r_{\max} }{ v_{\max} }. } \]

Timing Requirement from Attitude

\[ \boxed{ \Delta t_{\max} \le \frac{ \Delta\theta_{\max} }{ \omega_{\max} }. } \]

4.2.14.172 Key Takeaways

The most important concepts of time synchronization, latency, and delayed measurements are:

\[ \boxed{ \text{Update the State at the Measurement Epoch}. } \]

The most important synchronization principle is

\[ \boxed{ \text{Every Measurement Must Be Associated With the Correct Physical Time}. } \]

The most important delayed-measurement principle is

\[ \boxed{ \text{Correct the Historical State First, Then Propagate the Correction Forward}. } \]

And the most important warning is

\[ \boxed{ \text{A Perfect Measurement Applied at the Wrong Time Can Produce an Incorrect Navigation Update}. } \]

Next: 4.2.15 Measurement Validation and Innovation Gating

Once sensor measurements are properly synchronized and fused at the correct epoch, another question remains:

\[ \boxed{ \text{Should Every Available Measurement Be Trusted?} } \]

Real spacecraft sensors may produce

Therefore the estimator needs a systematic way to decide whether a measurement is statistically consistent with the predicted state.

For a predicted measurement

\[ \hat z \]

and actual measurement

\[ z, \]

define the innovation

\[ \boxed{ r = z-\hat z. } \]

Its covariance is

\[ \boxed{ S = HP^-H^T+R. } \]

A normalized statistical measure is

\[ \boxed{ NIS = r^TS^{-1}r. } \]

The next section should therefore develop 4.2.15 Measurement Validation and Innovation Gating, including:

4.2.15 Measurement Validation and Innovation Gating

Measurement residuals, innovation covariance, Mahalanobis distance, Normalised Innovation Squared, chi-square gates, measurement acceptance and rejection, adaptive and sensor-specific gating, outlier handling, fault detection, and RPO measurement validation.

Continue to Measurement Validation and Innovation Gating →