4.1.10 Sensor Specifications

Sensor specifications are the formal bridge between a component datasheet and spacecraft-level GNC performance. A datasheet value is meaningful only after its units, statistical definition, bandwidth, operating mode, environmental condition and confidence level are understood.

This chapter treats a sensor as a complete engineering system: measurement quality, noise and stability, dynamic response, timing, geometry, electrical and mechanical integration, radiation and environmental tolerance, qualification, reliability, firmware behaviour, SWaP and procurement risk.

The objective is to translate vendor information into quantities that GNC design can use directly: \(R\), \(Q\), \(P_0\), bias and scale-factor models, saturation limits, timing models, validity logic, Monte Carlo dispersions and requirement margins.

4.1.10.1 Why Sensor Specifications Matter

In spacecraft GNC, a datasheet value becomes useful only when it is connected to a mission requirement. Gyro bias becomes attitude drift, update rate limits estimator bandwidth, field of view determines reference availability, and latency converts spacecraft motion into time-alignment error. The engineering chain is therefore specification → physical meaning → GNC consequence → requirement margin.

Sensor selection is not simply choosing the device with the lowest quoted “accuracy.”

A complete spacecraft sensor must satisfy requirements in:

\[ \boxed{ \text{Measurement Performance} + \text{Dynamic Performance} + \text{Timing} + \text{Environment} + \text{Interfaces} + \text{Mass / Power} + \text{Reliability} } \]

A sensor that is extremely accurate but too slow, too power-hungry, not radiation tolerant, or outside the required dynamic range may be unsuitable.

4.1.10.2 Accuracy

Accuracy describes closeness to truth.

For measurement

\[ z_m \]

and true value

\[ z_t, \]

the measurement error is

\[ \boxed{ e=z_m-z_t } \]

Accuracy may be specified as:

absolute error,
percentage of full scale,
percentage of reading,
RMS error,
\(1\sigma\),
\(3\sigma\),
worst case,
CEP,
RMS angular error,
radial error.

These are not interchangeable.

4.1.10.3 Precision

Precision describes repeatability of measurements.

A sensor may have

\[ \boxed{ \text{High Precision} \quad\text{but}\quad \text{Low Accuracy} } \]

if repeated measurements cluster tightly around a biased value.

4.1.10.4 Accuracy vs Precision

Conceptually:

\[ \boxed{ \text{Accuracy} = \text{Closeness to Truth} } \] \[ \boxed{ \text{Precision} = \text{Closeness Between Repeated Measurements} } \]

This distinction is fundamental when evaluating sensor performance.

4.1.10.5 Resolution

Resolution is the smallest input change that can be distinguished.

For an \(N\)-bit converter over full-scale range

\[ FSR, \] \[ \boxed{ \Delta \approx \frac{FSR}{2^N} } \]

depending on encoding.

But digital bit depth does not guarantee true physical resolution because analog noise may dominate.

4.1.10.6 Effective Resolution

The effective resolution may be much worse than nominal ADC resolution.

If the LSB is smaller than sensor noise,

\[ \boxed{ \text{More Digital Bits} \not\Rightarrow \text{More Useful Information} } \]

This is particularly important for low-noise inertial and magnetic sensors.

4.1.10.7 Sensitivity

Sensitivity describes change in output per change in input:

\[ \boxed{ S = \frac{\Delta y}{\Delta x} } \]

For example:

V/\(g\),
counts/\(^{\circ}/s\),
V/T,
pixels/degree.

Sensitivity is not the same as resolution or accuracy.

4.1.10.8 Scale Factor

For ideal sensor response,

\[ y=Kx. \]

The coefficient \(K\) is the scale factor.

A scale-factor error is often written as

\[ \boxed{ y=(1+s)x } \]

where \(s\) is the fractional scale-factor error.

It may be specified in:

%,
ppm,
ppm/\(^{\circ}C\),
ppm/year.

4.1.10.9 Bias

Bias is an additive offset:

\[ \boxed{ z_m=z_{true}+b } \]

Bias may be quoted as:

zero bias,
initial bias,
turn-on bias,
bias repeatability,
bias instability,
bias temperature coefficient.

These terms refer to different behaviours and should not be treated as one specification.

4.1.10.10 Bias Repeatability

Bias repeatability describes how much initial bias changes between power cycles.

A typical model is

\[ \boxed{ b_0 \sim \mathcal N(\bar b,\sigma_b^2) } \]

This is often used as a run-to-run Monte Carlo uncertainty.

4.1.10.11 Bias Stability

Bias stability describes how the offset changes over time.

It can be given in units such as:

\[ ^\circ/hr, \quad \mu g, \quad nT. \]

But the datasheet definition must be checked carefully because “bias stability” and “bias instability” are sometimes used differently by vendors.

4.1.10.12 Bias Instability

Bias instability is usually a stochastic low-frequency term, commonly derived from Allan deviation.

It should not automatically be interpreted as:

\[ \boxed{ \text{Constant Bias} } \]

\[ \boxed{ \text{Random Walk} } \]

without understanding the manufacturer's test method.

4.1.10.13 Noise Density

Noise density is not a per-sample standard deviation by itself. The effective bandwidth and PSD convention determine the integrated RMS noise, so simulation and filter parameters must be derived from the configured sensor bandwidth rather than copied directly from a headline datasheet value.

Noise density is frequently specified as an amplitude spectral density:

\[ \boxed{ N_d } \]

with units such as

\[ \frac{^\circ/s}{\sqrt{\mathrm{Hz}}}, \quad \frac{m/s^2}{\sqrt{\mathrm{Hz}}}, \quad \frac{nT}{\sqrt{\mathrm{Hz}}}. \]

For approximately white noise over effective bandwidth \(B\),

\[ \boxed{ \sigma \approx N_d\sqrt{B} } \]

subject to PSD convention.

4.1.10.14 RMS Noise

RMS noise is already integrated over a particular bandwidth.

Therefore,

\[ \boxed{ \text{Noise Density} \neq \text{RMS Noise} } \]

unless the bandwidth is known.

4.1.10.15 Random Walk Specifications

Inertial sensors may specify:

Angle Random Walk,
Velocity Random Walk,
Rate Random Walk.

These coefficients arise from different stochastic processes.

They should not be mixed directly with:

bias instability,
static RMS noise,
scale-factor error.

4.1.10.16 Allan-Deviation Specifications

A good inertial datasheet may include an Allan deviation curve.

This can reveal:

quantization noise,
white noise,
bias instability,
random walk,
rate ramp.

The slope and coefficient interpretation must be consistent with units and Allan convention.

4.1.10.17 Bandwidth

Bandwidth must be assessed against spacecraft dynamics and control-loop bandwidth. Too little bandwidth creates lag and missed dynamics; unnecessarily high bandwidth passes more vibration and electronic noise. It is therefore a dynamic-response versus noise trade.

Sensor bandwidth defines the frequency range over which the sensor can track input dynamics.

A simple first-order model is

\[ \boxed{ G(s)=\frac{1}{\tau s+1} } \]

with

\[ \boxed{ f_c = \frac{1}{2\pi\tau} } \]

Higher bandwidth permits faster response, but generally admits more high-frequency noise.

4.1.10.18 Update Rate

The output update rate is

\[ \boxed{ f_s=\frac{1}{T_s} } \]

This is not necessarily equal to sensor analog bandwidth.

A device may have high internal bandwidth but output data at a slower digital rate.

4.1.10.19 Sampling Rate vs Output Rate

Some sensors internally sample much faster than their reported output rate.

Therefore:

\[ \boxed{ \text{Internal Sampling Rate} \neq \text{Output Data Rate} } \]

This matters when interpreting anti-aliasing, digital filtering, and latency.

4.1.10.20 Latency

Latency is a system-level GNC parameter because every measurement must be associated with the state that existed when it was physically taken. Deterministic delay can often be compensated; uncertain delay behaves as timing uncertainty and can create large innovations during fast motion.

Latency is the delay between the physical measurement epoch and when the value becomes available.

\[ \boxed{ \tau = t_{available}-t_{measurement} } \]

Latency matters strongly in fast spacecraft dynamics.

For attitude,

\[ \boxed{ \delta\theta \approx \omega\tau } \]

to first order.

4.1.10.21 Timestamp Accuracy

Timestamp error should be distinguished from latency.

Known delay may be corrected.

Unknown timestamp error produces a state mismatch:

\[ \boxed{ \delta r \approx v\,\delta t } \] \[ \boxed{ \delta\theta \approx \omega\,\delta t } \]

4.1.10.22 Jitter

Timing jitter is variation in sample time:

\[ \boxed{ t_k=kT_s+\delta t_k } \]

For rapidly changing measurements,

\[ \boxed{ \delta z \approx \dot z\,\delta t } \]

4.1.10.23 Dynamic Range

Dynamic range describes the span of measurable input values.

For a gyro:

\[ \boxed{ -\omega_{max} \le \omega \le \omega_{max} } \]

For an accelerometer:

\[ \boxed{ -a_{max} \le a \le a_{max} } \]

The required range must include expected mission extremes, not merely nominal operating values.

4.1.10.24 Full-Scale Range

Full-scale range is often written as:

±250°/s,
±16 g,
±1000 µT.

Selecting a larger full-scale range may reduce sensitivity or effective resolution.

Thus range and resolution involve a trade.

4.1.10.25 Saturation

A sensor saturates when input exceeds its measurable range.

\[ \boxed{ z_m = \operatorname{sat}(z,z_{min},z_{max}) } \]

Saturation is especially important during:

launch,
detumbling,
high-rate slews,
thruster firing,
close-range optical blinding.

4.1.10.26 Nonlinearity

Nonlinearity quantifies deviation from ideal proportional response.

\[ \boxed{ z_m = K_1z + K_2z^2 + K_3z^3+\cdots } \]

It may be specified as:

% of full scale,
ppm,
maximum deviation.

4.1.10.27 Cross-Axis Sensitivity

For vector sensors:

\[ \boxed{ z_{m,x} = z_x + c_{xy}z_y + c_{xz}z_z } \]

Cross-axis sensitivity may be specified as a percentage.

It is especially important in:

gyros,
accelerometers,
magnetometers.

4.1.10.28 Axis Misalignment

A sensor may specify orthogonality or alignment error in:

degrees,
arcminutes,
arcseconds,
milliradians.

This must be distinguished from spacecraft-level installation misalignment.

The total alignment error may contain:

\[ \boxed{ \text{Internal Sensor Misalignment} + \text{Mounting Misalignment} + \text{Structural Deformation} } \]

4.1.10.29 Temperature Range

Sensors normally specify:

operating temperature,
storage temperature.

These are not the same.

A device may survive a broad storage range but only meet accuracy specifications over a narrower operating range.

4.1.10.30 Temperature Coefficients

Important thermal specifications include:

\[ \boxed{ \frac{db}{dT} } \]

and

\[ \boxed{ \frac{ds}{dT} } \]

for bias and scale factor.

These may be quoted as:

°/s/°C,
µg/°C,
ppm/°C,
nT/°C.

4.1.10.31 Thermal Stability

It is useful to distinguish:

instantaneous temperature coefficient,
warm-up drift,
thermal cycling repeatability,
gradient sensitivity.

High-accuracy sensors may require thermal control rather than only calibration.

4.1.10.32 Warm-Up Time

Some sensors require a stabilization period after power-on.

\[ \boxed{ t_{warmup} } \]

can influence mission readiness after reset or safe-mode recovery.

4.1.10.33 Magnetic Sensitivity

For sensors not intended to measure magnetic field, magnetic susceptibility may still matter.

For magnetometers, spacecraft-generated fields are often a dominant integration concern.

Relevant specifications can include:

sensitivity,
maximum field,
magnetic offset,
noise,
linearity.

4.1.10.34 g-Sensitivity

Gyroscope datasheets may specify sensitivity to linear acceleration.

\[ \boxed{ \omega_{error} = K_g a } \]

Units may be:

\[ \frac{^\circ/s}{g} \]

or equivalent.

This matters during launch and thruster firing.

4.1.10.35 Vibration Sensitivity

Performance under vibration may differ greatly from static laboratory performance.

Look for:

random vibration qualification,
sinusoidal vibration,
vibration rectification error,
microvibration sensitivity.

This can matter for reaction-wheel spacecraft.

4.1.10.36 Shock

Launch and separation events can generate high mechanical shock.

Important specifications include:

survivable shock,
operational shock,
pyroshock qualification.

Survival does not imply full measurement accuracy during shock.

4.1.10.37 Radiation Tolerance

Radiation tolerance must be reviewed against orbit, mission duration, shielding, technology and fault-recovery strategy. A device can survive total dose yet still suffer single-event resets or latch-up, so cumulative degradation and transient-event susceptibility must both be considered.

Spacecraft sensors may need tolerance to:

\[ \boxed{ \text{TID} + \text{SEE} + \text{Displacement Damage} } \]

depending on technology.

Radiation specifications can include:

total ionizing dose,
SEL threshold,
SEU rate,
proton fluence.

4.1.10.38 Total Ionizing Dose

TID is accumulated radiation exposure.

It is typically specified in:

\[ \boxed{ krad(Si) } \]

or similar units.

Mission requirement depends on:

orbit,
duration,
shielding.

4.1.10.39 Single-Event Effects

SEE may include:

SEU,
SEL,
SEFI,
SET.

Sensor selection should consider whether a transient upset merely corrupts one sample or can reset/damage the sensor.

4.1.10.40 Space Qualification

Labels such as space-grade, space-qualified, radiation tolerant, radiation hardened and flight-proven are not equivalent. The meaningful evidence is the exact tested configuration, test standard, environmental level, margin and relevance to the intended mission.

Terms such as:

space-qualified,
space-grade,
radiation tolerant,
radiation hardened,
flight heritage

are not equivalent.

The qualification standard and tested environment should be checked.

4.1.10.41 Flight Heritage

Flight heritage means previous use in space, but the value depends on:

orbit,
duration,
mission environment,
unit configuration,
qualification level.

A device flown once in benign LEO does not automatically prove suitability for every mission.

4.1.10.42 Reliability

Reliability may be expressed through:

\[ \boxed{ MTBF } \]

or component failure rates.

For spacecraft, mission reliability also depends on:

redundancy,
derating,
radiation,
thermal cycling,
connector/interface reliability.

4.1.10.43 Mass

Sensor mass contributes directly to spacecraft mass budget:

\[ \boxed{ m_{sensor} } \]

but mounting brackets, harnesses, electronics, thermal hardware, and redundant units may add significant system mass.

4.1.10.44 Power Consumption

Power may have several operating states:

\[ \boxed{ P_{startup}, P_{acquisition}, P_{tracking}, P_{idle}, P_{peak}. } \]

Using only a single “typical power” value can underestimate spacecraft power requirements.

4.1.10.45 Voltage and Current

Important electrical specifications include:

supply voltage,
voltage tolerance,
startup current,
steady-state current,
inrush current.

Inrush can be particularly important for small spacecraft power systems.

4.1.10.46 Interface Type

Possible interfaces include:

UART,
RS-422,
CAN,
SPI,
I²C,
Ethernet,
SpaceWire,
MIL-STD-1553,
custom LVDS.

Interface choice affects:

bandwidth,
cabling,
timing,
flight-computer compatibility.

4.1.10.47 Data Rate

Sensor data rate is approximately

\[ \boxed{ R_d = N_{bytes} \times f_s } \]

plus protocol overhead.

High-rate cameras and LiDAR can dominate spacecraft data buses.

4.1.10.48 Packet Structure

A useful sensor packet may include:

\[ \boxed{ \{ measurement,\, timestamp,\, status,\, quality,\, temperature,\, checksum \} } \]

Availability of quality/status information can be as important as raw measurement accuracy.

4.1.10.49 Time Synchronization Interfaces

High-quality multi-sensor fusion depends on a common time base. PPS, external triggers, hardware timestamps and synchronized clocks allow IMU, GNSS, star-tracker, camera and LiDAR measurements to be aligned at the estimator epoch instead of being fused with hidden bus or processing delays.

Important timing capabilities include:

PPS,
external trigger,
hardware timestamp,
clock input,
synchronization pulse.

These are critical for high-accuracy multi-sensor fusion.

4.1.10.50 Field of View

Optical sensors have finite FOV.

For a star tracker or Sun sensor:

\[ \boxed{ \theta_{FOV} } \]

determines whether the reference can be observed.

Field of view affects:

acquisition,
availability,
sensor placement,
redundancy.

4.1.10.51 Exclusion Angles

Star trackers often specify exclusion angles relative to:

Sun,
Earth limb,
Moon.

These are not the same as FOV.

An object can be outside the imaging FOV but still cause stray-light problems.

4.1.10.52 Boresight Accuracy

Optical sensors may specify boresight accuracy or knowledge error.

This must be distinguished from:

centroiding accuracy,
relative pointing accuracy,
absolute alignment to spacecraft body.

4.1.10.53 Angular Resolution

For optical sensors,

\[ \boxed{ \delta\theta } \]

may be reported in:

degrees,
arcminutes,
arcseconds,
microradians.

Convert carefully.

\[ \boxed{ 1\ \text{arcsec} = 4.848\times10^{-6}\ \text{rad} } \]

approximately.

4.1.10.54 Star-Tracker Accuracy

Star-tracker performance is often anisotropic: cross-boresight accuracy can differ markedly from around-boresight accuracy, while acquisition accuracy can differ from tracking accuracy. A single headline attitude number may therefore be insufficient for a realistic MEKF covariance.

Star trackers may specify:

cross-boresight accuracy,
around-boresight accuracy,
attitude knowledge,
acquisition accuracy,
tracking accuracy.

These values should not be collapsed into one number.

4.1.10.55 Star-Tracker Update Rate

Tracking rate can influence attitude filter bandwidth.

Typical GNC logic may be:

\[ \boxed{ \text{Gyro High Rate} + \text{Star Tracker Lower Rate} } \]

Therefore star-tracker update rate must be adequate to bound gyro drift.

4.1.10.56 Star-Tracker Slew-Rate Limit

A star tracker may lose tracking above some angular rate:

\[ \boxed{ |\omega| > \omega_{track,max} } \]

The maximum acquisition rate and maximum tracking rate may be different.

4.1.10.57 Lost-in-Space Acquisition Time

A star tracker may specify:

\[ \boxed{ t_{LIS} } \]

for autonomous initial attitude acquisition.

This can affect recovery after spacecraft reset.

4.1.10.58 Sun-Sensor Accuracy

Sun-sensor accuracy may depend on:

incidence angle,
FOV position,
intensity,
temperature,
albedo.

Therefore a single nominal angular accuracy may not describe full performance.

4.1.10.59 Sun-Sensor FOV

Coarse Sun sensors often provide broad coverage.

Fine Sun sensors may provide:

\[ \boxed{ \text{Higher Accuracy} \quad\text{but}\quad \text{Narrower FOV}. } \]

This creates an acquisition-versus-precision trade.

4.1.10.60 Magnetometer Range

The measurement range must accommodate both:

\[ \boxed{ \text{Environmental Magnetic Field} + \text{Spacecraft-Generated Field}. } \]

Insufficient range may cause saturation near magnetorquer operation or onboard magnetic sources.

4.1.10.61 Magnetometer Noise

Magnetometer noise density is often quoted in

\[ \boxed{ nT/\sqrt{Hz} } \]

\[ pT/\sqrt{Hz}. \]

But spacecraft magnetic contamination may dominate sensor intrinsic noise.

4.1.10.62 Magnetometer Offset

Offset may be specified in:

\[ \boxed{ nT } \]

or as % of full scale.

For spacecraft integration, hard-iron calibration and mounting location can be as important as factory offset.

4.1.10.63 Gyroscope Range

Gyro range must cover:

nominal pointing,
detumbling,
safe mode,
launch/separation transient,
commanded slew.

A fine-pointing gyro with insufficient rate range may saturate during recovery.

4.1.10.64 Gyroscope ARW

Angle random walk is an important inertial specification.

Depending on units, it may be reported as

\[ ^\circ/\sqrt{hr} \]

or equivalent.

It should be interpreted carefully before conversion into discrete process noise.

4.1.10.65 Gyroscope Bias Instability

Usually given in

\[ ^\circ/hr. \]

This is often one of the headline numbers used to compare gyros.

But two sensors with identical bias-instability numbers can still have very different:

ARW,
range,
bandwidth,
temperature sensitivity,
radiation performance.

4.1.10.66 Accelerometer Range

Accelerometer range must consider:

launch acceleration,
thruster maneuvers,
vibration,
on-orbit low-acceleration navigation.

A wide range may reduce low-level resolution.

4.1.10.67 Accelerometer Noise Density

May be specified as

\[ \boxed{ \mu g/\sqrt{Hz} } \]

\[ \boxed{ m/s^2/\sqrt{Hz}. } \]

The required noise level depends strongly on whether the accelerometer is used for:

coarse dynamics,
precise orbit determination,
drag-free control,
inertial navigation.

4.1.10.68 Accelerometer Bias

Bias directly affects integrated velocity and position.

\[ \boxed{ \delta v\approx b_a t } \] \[ \boxed{ \delta r\approx\frac12b_a t^2 } \]

Thus accelerometer bias can be much more important than instantaneous noise in long-duration inertial navigation.

4.1.10.69 GNSS Position Accuracy

GNSS position accuracy should be interpreted together with geometry, antenna performance, receiver mode and the statistical definition used. For RPO, raw observables, timing, common-satellite tracking and relative-solution covariance can be more important than standalone PVT accuracy.

GNSS may specify:

horizontal accuracy,
vertical accuracy,
3-D RMS,
CEP,
\(1\sigma\),
\(2\sigma\).

These metrics must not be compared without conversion and definition.

4.1.10.70 GNSS Velocity Accuracy

Velocity accuracy may be derived from Doppler and can be much better than finite-differencing successive position solutions.

Check whether the quoted specification is:

per-axis,
horizontal,
3-D,
RMS.

4.1.10.71 GNSS Timing Accuracy

GNSS receivers may specify:

PPS accuracy,
timing RMS,
jitter,
absolute time error.

This can be critical for sensor synchronization and formation flying.

4.1.10.72 GNSS Update Rate

GNSS PVT update rates may range widely.

The required rate depends on:

\[ \boxed{ \text{Spacecraft Dynamics} + \text{Navigation Filter} + \text{RPO Requirements} } \]

High update rate is particularly valuable for proximity operations.

4.1.10.73 GNSS Time to First Fix

Important quantities include:

cold start TTFF,
warm start TTFF,
hot start TTFF,
reacquisition time.

These affect fault recovery.

4.1.10.74 GNSS Tracking Sensitivity

Signal sensitivity may be specified for:

acquisition,
tracking,
reacquisition.

Tracking sensitivity is generally better than acquisition sensitivity.

4.1.10.75 GNSS Raw Measurement Availability

Raw pseudorange, Doppler, carrier phase and signal-quality outputs enable tightly coupled GNSS/INS, differential processing, carrier-phase relative navigation and custom integrity monitoring. A receiver that outputs only PVT restricts the estimator architecture even if its standalone accuracy is good.

For advanced navigation, check whether receiver outputs:

\[ \boxed{ \rho,\quad \Phi,\quad D,\quad C/N_0 } \]

rather than only PVT.

This is crucial for:

tightly coupled GNSS/INS,
differential GNSS,
carrier-phase RPO.

4.1.10.76 GNSS Dynamic Limits

For space use, check:

maximum altitude,
maximum velocity,
acceleration,
jerk,
Doppler search range.

A terrestrial receiver may be unsuitable despite excellent static accuracy.

4.1.10.77 Antenna Specifications

For GNSS, RF, and some other sensors, antenna performance is part of system performance.

Important parameters include:

gain,
radiation pattern,
polarization,
bandwidth,
axial ratio,
phase-centre variation,
noise figure for active antennas.

4.1.10.78 LiDAR Range

LiDAR datasheets may specify:

\[ \boxed{ \rho_{min}, \quad \rho_{max} } \]

but maximum range often depends on:

target reflectivity,
incidence angle,
aperture,
illumination,
atmospheric conditions for terrestrial systems.

Spacecraft target surface properties therefore matter.

4.1.10.79 LiDAR Range Accuracy

Range accuracy may be written as

\[ \boxed{ \sigma_\rho } \]

or maximum error.

It can depend on:

range,
target reflectivity,
signal strength,
averaging.

4.1.10.80 LiDAR Range Resolution

Range resolution is not necessarily the same as range accuracy.

A device may report millimetre digital resolution while having centimetre absolute accuracy.

4.1.10.81 LiDAR Angular Resolution

Scanning LiDAR may specify angular step or beam divergence.

These influence:

point density,
target feature resolution,
relative pose observability.

4.1.10.82 Camera Resolution

Camera resolution in pixels alone does not define navigation accuracy.

Relative-navigation performance also depends on:

\[ \boxed{ \text{Focal Length} + \text{Pixel Pitch} + \text{Optics} + \text{Feature Algorithm} + \text{Range} } \]

4.1.10.83 Instantaneous Field of View

For a camera pixel,

\[ \boxed{ IFOV \approx \frac{p}{f} } \]

for small angles, where:

\(p\) = pixel pitch,
\(f\) = focal length.

This connects detector geometry to angular resolution.

4.1.10.84 Camera Frame Rate

Frame rate determines temporal update rate:

\[ \boxed{ f_{camera}. } \]

A higher frame rate improves dynamic tracking but increases:

data rate,
processing load,
power.

4.1.10.85 Camera Exposure Time

Long exposure improves photon collection but increases motion blur.

Angular blur is approximately

\[ \boxed{ \delta\theta_{blur} \approx \omega t_{exp} } \]

during constant-rate motion.

4.1.10.86 Signal-to-Noise Ratio

SNR is commonly defined as

\[ \boxed{ SNR = \frac{P_{signal}}{P_{noise}} } \]

or in decibels,

\[ \boxed{ SNR_{dB} = 10\log_{10} \left( \frac{P_s}{P_n} \right). } \]

For amplitude quantities, the \(20\log_{10}\) form is used.

4.1.10.87 Dynamic Accuracy

Bench accuracy can differ substantially from operational accuracy under slew, vibration, thermal transients, motion blur, RF dynamics or digital filtering. Qualification and GNC analysis should therefore include mission-representative dynamic conditions.

Static accuracy and dynamic accuracy can differ substantially.

For example, star-tracker accuracy during high slew may be worse than while stationary.

Thus:

\[ \boxed{ \text{Bench Accuracy} \neq \text{Operational Accuracy} } \]

4.1.10.88 Absolute vs Relative Accuracy

Absolute accuracy references an external truth.

Relative accuracy describes change or consistency over a shorter interval.

Examples include:

absolute attitude knowledge,
relative pointing error,
absolute position,
relative baseline accuracy.

These specifications support different mission requirements.

4.1.10.89 Short-Term vs Long-Term Stability

Short-term sensor performance may be dominated by white noise.

Long-term performance may be dominated by:

bias drift,
thermal effects,
ageing,
radiation.

Therefore qualification should consider the relevant mission time scale.

4.1.10.90 Repeatability

Repeatability can be specified across:

repeated measurements,
power cycles,
temperature cycles,
installation cycles.

The exact test definition matters.

4.1.10.91 Reproducibility

Reproducibility concerns agreement under changed conditions such as:

different units,
different labs,
different operators,
different environments.

It is broader than repeatability.

4.1.10.92 Calibration Accuracy

A manufacturer may provide factory calibration.

But residual calibration uncertainty should be distinguished from total operational accuracy.

Spacecraft integration may require additional:

alignment calibration,
thermal calibration,
magnetic calibration,
boresight calibration.

4.1.10.93 Calibration Interval

Some sensors require periodic recalibration.

For space missions, this may need to be achieved through:

onboard estimation,
celestial references,
ground processing,
calibration maneuvers.

4.1.10.94 Stability Over Life

Important long-term parameters include:

\[ \boxed{ \frac{db}{dt}, \quad \frac{ds}{dt}, \quad \frac{d\theta_{align}}{dt} } \]

where relevant.

These may be poorly characterized in short commercial datasheets.

4.1.10.95 Availability

Availability is a mission-performance quantity, not a secondary statistic. A highly accurate sensor may still be unsuitable for a critical phase if eclipse, blinding, acquisition delay, geometry or thermal constraints make it unavailable too often.

Sensor availability is

\[ \boxed{ A = \frac{T_{valid}}{T_{mission}} } \]

approximately.

Availability is distinct from accuracy.

A very accurate sensor with frequent invalid periods may still require strong backup architecture.

4.1.10.96 Continuity

Continuity describes probability of maintaining valid service without unexpected interruption over a required interval.

This is particularly important during:

docking,
landing,
critical burns.

4.1.10.97 Integrity

Integrity concerns whether a sensor or navigation system can indicate when its output should not be trusted.

This may include:

status flags,
health indicators,
self-test,
residual monitoring.

4.1.10.98 Built-In Test

A sensor may support:

\[ \boxed{ BIT } \]

\[ \boxed{ BITE } \]

for built-in test equipment.

Check whether it detects:

hardware faults,
memory faults,
temperature issues,
optical obscuration,
calibration faults.

4.1.10.99 Quality Flags

Useful sensor outputs include:

validity,
confidence,
tracked stars,
satellites used,
SNR,
saturation,
temperature,
tracking mode.

These can be directly used for adaptive covariance and FDIR.

4.1.10.100 Startup Time

Startup time may include:

\[ \boxed{ \text{Power-On} \rightarrow \text{Self-Test} \rightarrow \text{Warm-Up} \rightarrow \text{Acquisition} \rightarrow \text{Valid Data}. } \]

These are different stages.

4.1.10.101 Recovery Time

After reset, dropout, or blinding, how long until valid measurements return?

This can be more operationally important than initial startup time.

4.1.10.102 Size and Envelope

Physical dimensions affect:

spacecraft accommodation,
optical FOV,
thermal design,
harness routing,
placement relative to centre of mass.

4.1.10.103 Mounting Requirements

Important considerations include:

mounting flatness,
bolt pattern,
thermal interface,
vibration isolation,
alignment datum.

Precision sensors may require strict mechanical tolerances.

4.1.10.104 Sensor Reference Frame Definition

The datasheet should define:

\[ \boxed{ S=\{x_s,y_s,z_s\} } \]

and sign conventions.

Without this, sensor-to-body transformation cannot be implemented correctly.

4.1.10.105 Alignment Datum

For high-accuracy systems, check whether alignment is referenced to:

mechanical housing,
optical boresight,
connector datum,
calibrated internal axes.

The physical datum must be usable during spacecraft integration.

4.1.10.106 Connector and Harness

Practical specifications include:

connector type,
pin count,
shielding,
cable impedance,
maximum harness length.

These can affect EMC and timing.

4.1.10.107 EMC / EMI Compatibility

Sensor qualification should include electromagnetic compatibility.

Check:

conducted emissions,
radiated emissions,
conducted susceptibility,
radiated susceptibility.

Magnetometers require especially careful placement.

4.1.10.108 Vacuum Compatibility

For space hardware, materials should satisfy appropriate outgassing and vacuum compatibility requirements.

Optical sensors can be especially sensitive to contamination.

4.1.10.109 Contamination Sensitivity

Star trackers, cameras, and Sun sensors can degrade because of:

deposition,
molecular contamination,
particulate contamination.

This may not appear prominently in a generic commercial datasheet.

4.1.10.110 Thermal Interface

A sensor may dissipate

\[ P_{sensor} \]

but allowable baseplate temperature and thermal resistance also matter.

Thermal design should consider both electrical power and heat rejection.

4.1.10.111 Operational Life

Check whether the sensor has limits on:

hours of operation,
detector life,
laser life,
mechanical scanner cycles,
power cycles.

This is particularly relevant for active optical sensors and mechanisms.

4.1.10.112 Redundancy Capability

The sensor may support:

dual power inputs,
dual communication ports,
redundant heads,
cross-strapping.

This can simplify spacecraft fault-tolerant architecture.

4.1.10.113 Qualification Level

Possible hardware categories include:

engineering model,
qualification model,
protoflight model,
flight model.

Performance and documentation requirements differ.

4.1.10.114 Qualification Testing

Typical spacecraft sensor qualification may include:

vibration,
shock,
thermal vacuum,
thermal cycling,
EMC/EMI,
radiation,
life testing.

The exact program depends on mission and standards.

4.1.10.115 Acceptance Testing

Qualification proves design margin.

Acceptance testing verifies each flight unit.

These are not the same.

4.1.10.116 Heritage vs Qualification

A sensor with heritage may still require additional qualification if:

mission environment differs,
packaging changed,
firmware changed,
radiation level differs,
mounting configuration differs.

4.1.10.117 Software and Firmware

For intelligent sensors, firmware is part of sensor performance.

Check:

version control,
update capability,
bootloader,
fault recovery,
deterministic timing.

4.1.10.118 Output Determinism

Some GNC systems require deterministic timing.

A sensor may report an average latency but exhibit variable processing delay.

Thus both

\[ \boxed{ \tau_{mean} } \]

and

\[ \boxed{ \sigma_\tau } \]

may matter.

4.1.10.119 Fixed vs Configurable Parameters

Sensors may allow configuration of:

range,
bandwidth,
output rate,
digital filtering,
integration time,
tracking mode.

Performance specifications may depend on those settings.

4.1.10.120 Configuration-Dependent Noise

For example, increasing bandwidth can increase RMS noise:

\[ \boxed{ \sigma \propto \sqrt{B} } \]

Therefore datasheet noise values should be associated with the configuration in which they were measured.

4.1.10.121 Configuration-Dependent Latency

Digital filtering can reduce noise but increase group delay.

Thus:

\[ \boxed{ \text{More Filtering} \rightarrow \text{Less Noise} + \text{More Latency} } \]

This is a direct GNC trade.

4.1.10.122 Noise-Bandwidth Trade

A wider bandwidth:

\[ \boxed{ B\uparrow } \]

typically gives

\[ \boxed{ \text{Faster Response} } \]

but also

\[ \boxed{ \sigma_{noise}\uparrow. } \]

This is a fundamental sensor-control trade.

4.1.10.123 Range-Resolution Trade

For some sensing systems:

\[ \boxed{ \text{Larger Full Scale} \rightarrow \text{Worse Resolution} } \]

for fixed ADC bit depth.

The optimum range should therefore cover expected dynamics with reasonable margin.

4.1.10.124 Accuracy-Power Trade

Higher-performance sensors often consume more power.

For example:

\[ \boxed{ \text{MEMS IMU} \rightarrow \text{Low Power / Lower Precision} } \]

versus

\[ \boxed{ \text{FOG / RLG} \rightarrow \text{Higher Precision / Higher SWaP} } \]

in many implementations.

4.1.10.125 Accuracy-Mass Trade

High-precision optical or inertial sensors may require:

larger optics,
better thermal design,
mechanical isolation.

Thus accuracy can increase system-level mass.

4.1.10.126 Performance vs Cost

Sensor trade studies should avoid assuming:

\[ \boxed{ \text{Highest Cost} = \text{Best Mission Choice}. } \]

The correct sensor is the one that satisfies mission requirements with acceptable margin and risk.

4.1.10.127 SWaP

A common comparison metric is

\[ \boxed{ SWaP = \text{Size} + \text{Weight} + \text{Power}. } \]

Sometimes cost is included as

\[ \boxed{ SWaP-C. } \]

This is particularly important for CubeSats.

4.1.10.128 Datasheet Typical vs Maximum

Typical values are often representative, not guaranteed. Hard mission requirements should preferably be checked against guaranteed or qualified limits, with margin for temperature, ageing, radiation, alignment and modelling uncertainty.

Datasheets may quote:

typical,
nominal,
guaranteed,
maximum,
minimum.

A “typical” value is not necessarily guaranteed.

For requirement verification, worst-case guaranteed values are often more appropriate.

4.1.10.129 Typical vs \(1\sigma\)

Typical does not automatically mean

\[ 1\sigma. \]

Unless the manufacturer explicitly states a statistical confidence, no probability interpretation should be assumed.

4.1.10.130 Maximum Error vs RMS Error

A maximum error is a bound.

RMS is a statistical metric.

Thus:

\[ \boxed{ e_{max} \neq \sigma } \]

and should not be inserted directly into a Kalman-filter \(R\) matrix.

4.1.10.131 Full Scale vs Reading Percentage

These specifications behave differently.

For

\[ \pm100 \]

full scale, \(1\%\) FS means a constant 1-unit error.

But \(1\%\) of reading means error scales with actual measurement.

This distinction matters at small signals.

4.1.10.132 ppm

Parts per million means

\[ \boxed{ 1\ ppm=10^{-6} } \]

Therefore:

\[ 100\ ppm = 10^{-4} = 0.01\%. \]

This is frequently used for precision scale factors and oscillators.

4.1.10.133 Temperature Coefficient in ppm/°C

If scale factor has coefficient

\[ k_T \]

in ppm/°C,

\[ \boxed{ \frac{\Delta K}{K} = k_T\times10^{-6}\Delta T. } \]

This converts datasheet coefficients into simulation parameters.

4.1.10.134 dB Specifications

Some sensor/RF parameters are given in decibels.

For power ratio:

\[ \boxed{ G_{dB} = 10\log_{10} \left( \frac{P_2}{P_1} \right). } \]

For amplitude ratio under equal impedance:

\[ \boxed{ G_{dB} = 20\log_{10} \left( \frac{A_2}{A_1} \right). } \]

4.1.10.135 Unit Conversion Discipline

Before comparing sensors, normalize units.

Examples:

\[ ^\circ/s \leftrightarrow rad/s \] \[ ^\circ/hr \leftrightarrow rad/s \] \[ \mu g \leftrightarrow m/s^2 \] \[ nT \leftrightarrow T. \]

Unit errors can easily produce factors of thousands or millions.

4.1.10.136 Angular Unit Conversion

\[ \boxed{ 1^\circ = \frac{\pi}{180}\ rad } \] \[ \boxed{ 1\ arcmin = \frac{\pi}{10800}\ rad } \] \[ \boxed{ 1\ arcsec = \frac{\pi}{648000}\ rad. } \]

4.1.10.137 Acceleration Unit Conversion

\[ \boxed{ 1g \approx 9.80665\ m/s^2. } \]

Therefore,

\[ \boxed{ 1\ \mu g \approx 9.80665\times10^{-6}\ m/s^2. } \]

4.1.10.138 Magnetic Unit Conversion

\[ \boxed{ 1\ T = 10^6\ \mu T = 10^9\ nT. } \]

Spacecraft geomagnetic measurements are often expressed in nT or µT.

4.1.10.139 Error Specification to Covariance

Only random measurement uncertainty at the update epoch belongs directly in \(R\). Bias, bias random walk, scale-factor uncertainty, alignment and latency may instead require calibration, state augmentation, process noise or a more complete timing/measurement model.

Suppose the manufacturer explicitly states a one-axis \(1\sigma\) accuracy:

\[ \sigma. \]

Then

\[ \boxed{ R=\sigma^2 } \]

for that scalar measurement.

For three independent axes:

\[ \boxed{ R= \operatorname{diag} ( \sigma_x^2, \sigma_y^2, \sigma_z^2 ). } \]

But only use this when the statistical interpretation is justified.

4.1.10.140 \(3\sigma\) to \(1\sigma\)

If a Gaussian specification explicitly states

\[ E_{3\sigma}, \]

then

\[ \boxed{ \sigma = \frac{E_{3\sigma}}{3}. } \]

This conversion is invalid if the quoted “maximum” is not a Gaussian \(3\sigma\) quantity.

4.1.10.141 RMS to Standard Deviation

If error is zero mean,

\[ \boxed{ RMSE=\sigma. } \]

But if bias exists,

\[ \boxed{ RMSE^2 = b^2+\sigma^2. } \]

So RMS accuracy should not automatically be interpreted as zero-mean measurement noise.

4.1.10.142 Datasheet Noise to Simulation

A robust conversion records the original vendor unit and test condition, normalizes the value, identifies whether it is density, RMS, a bound or a stability coefficient, and then maps it into the correct discrete-time model. This preserves traceability and avoids silent statistical errors.

A practical workflow is

\[ \boxed{ \text{Datasheet Noise Specification} \rightarrow \text{Interpret Units / Bandwidth} \rightarrow \text{Convert to Standard Deviation} \rightarrow \text{Discrete Noise Model} } \]

rather than copying the datasheet number directly into Simulink.

4.1.10.143 Datasheet Bias to Monte Carlo

A useful distinction is:

Initial bias uncertainty

Sample once:

\[ \boxed{ b_0^{(j)} \sim \mathcal D_b. } \]

Time-varying bias

Propagate:

\[ \boxed{ b_{k+1} = \phi b_k+w_k. } \]

These correspond to different datasheet parameters.

4.1.10.144 Datasheet Latency to Model

If latency is fixed:

\[ \boxed{ z(t) = h[x(t-\tau)]. } \]

If latency varies:

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

This distinction matters in high-dynamic navigation.

4.1.10.145 Sensor Specification Matrix

Keep both the vendor-original value and a normalized engineering value. All candidates should be compared using common units, confidence level, bandwidth, temperature, operating mode and qualification assumptions.

For every candidate sensor, I would create a common comparison sheet with fields like:

Category	Parameter
Measurement	Quantity measured
Accuracy	\(1\sigma\), RMS, max
Precision	Repeatability
Resolution	Digital/effective
Bias	Initial/turn-on
Stability	Bias instability/drift
Noise	Density/RMS
Scale factor	Error/stability
Alignment	Orthogonality/misalignment
Range	Full scale
Bandwidth	Hz
Update rate	Hz
Latency	ms
Temperature	Operating/storage
Radiation	TID/SEE
Mechanical	Vibration/shock
Interface	UART/SPI/CAN/etc.
Timing	PPS/trigger/timestamp
Mass	g/kg
Power	W
Dimensions	mm
Qualification	TVAC/vibration/etc.
Heritage	Missions/flights
Availability	Lead time
Cost	Unit price

4.1.10.146 Sensor-Specific Specification Matrix

Then add type-specific fields.

Gyro

ARW,
bias instability,
rate random walk,
g-sensitivity.

Accelerometer

VRW,
bias stability,
vibration rectification.

Magnetometer

field range,
field noise,
hard/soft-iron sensitivity.

Star tracker

cross-boresight accuracy,
roll accuracy,
FOV,
exclusion angles,
LIS time,
max slew.

Sun sensor

angular accuracy,
FOV,
linearity,
albedo sensitivity.

GNSS

PVT accuracy,
raw measurement output,
constellations,
frequencies,
altitude/dynamic capability,
TTFF.

Camera

resolution,
FOV,
focal length,
frame rate,
exposure.

LiDAR

min/max range,
range accuracy,
angular resolution,
point rate,
FOV.

4.1.10.147 Specification Compliance

For requirement

\[ p\le p_{req}, \]

sensor compliance should include margin:

\[ \boxed{ M = p_{req}-p_{sensor} } \]

for an upper-limit parameter.

For minimum requirements such as update rate:

\[ \boxed{ M = p_{sensor}-p_{req}. } \]

Positive margin is preferable.

4.1.10.148 Requirement Margin

A sensor that barely meets nominal requirement may fail after:

temperature degradation,
radiation,
ageing,
mounting error.

Therefore system margin must account for mission environment and uncertainty.

4.1.10.149 Worst-Case Specification

A robust comparison should consider:

\[ \boxed{ \text{Nominal} } \] \[ \boxed{ \text{Typical} } \] \[ \boxed{ \text{Worst Case} } \]

separately.

A sensor selected only from typical performance can create verification problems later.

4.1.10.150 Beginning-of-Life vs End-of-Life

Spacecraft sensor performance may change from BOL to EOL.

Thus:

\[ \boxed{ \text{Requirement Compliance at BOL} \not\Rightarrow \text{Requirement Compliance at EOL}. } \]

Consider:

radiation,
ageing,
thermal cycling,
calibration drift.

4.1.10.151 Qualification Margin

Environmental qualification normally includes margin over expected mission conditions.

For example:

\[ \boxed{ T_{qual} > T_{mission} } \]

or vibration levels above predicted flight loads.

The exact margin depends on the qualification standard.

4.1.10.152 Sensor Procurement Specification

The procurement specification becomes the technical contract connecting the component to spacecraft verification. It should define performance, interfaces, environmental envelope, qualification evidence, calibration deliverables, software/firmware configuration, documentation and acceptance criteria.

A procurement specification should state required:

performance,
environment,
interfaces,
qualification,
documentation,
calibration,
delivery conditions.

This reduces ambiguity with vendors.

4.1.10.153 Questions to Ask a Sensor Vendor

For spacecraft procurement, useful questions include:

Is the quoted accuracy typical, RMS, \(1\sigma\), \(3\sigma\), or maximum?
Under what temperature was it measured?
At what bandwidth and output rate?
What is the latency?
Is the latency deterministic?
What is the sensor-frame definition?
Are raw measurements available?
Is covariance or quality information provided?
What calibration is performed?
What is the post-calibration residual?
What environmental qualification has been completed?
What radiation testing exists?
What vibration/shock testing exists?
What flight heritage exists?
Are qualification reports available?
What firmware version was tested?
What is the lead time?
Are export restrictions applicable?
What is the expected lifetime?
What failure/status outputs are available?

4.1.10.154 Sensor Specification to GNC Requirement

Every important datasheet parameter should trace to a GNC consequence in the error budget, estimator, controller, availability analysis or mission-mode logic. Prominent marketing parameters should not dominate the trade unless they matter to the mission.

Every datasheet parameter should be linked to a GNC consequence.

For example:

\[ \boxed{ \text{Gyro Bias} \rightarrow \text{Attitude Drift} } \] \[ \boxed{ \text{Accelerometer Bias} \rightarrow \text{Velocity / Position Drift} } \] \[ \boxed{ \text{Star Tracker Accuracy} \rightarrow \text{Attitude Knowledge Error} } \] \[ \boxed{ \text{GNSS Accuracy} \rightarrow \text{Orbit / Relative Navigation Error} } \] \[ \boxed{ \text{Latency} \rightarrow \text{Dynamic State Error} } \] \[ \boxed{ \text{Update Rate} \rightarrow \text{Estimator Bandwidth} } \] \[ \boxed{ \text{FOV} \rightarrow \text{Measurement Availability}. } \]

4.1.10.155 Sensor Specification to Simulation Parameter

The conversion chain should be

\[ \boxed{ \text{Datasheet} \rightarrow \text{Interpretation} \rightarrow \text{Engineering Parameter} \rightarrow \text{Simulation Model} } \]

Example:

\[ \boxed{ \text{Noise Density} \rightarrow \sigma \rightarrow R } \] \[ \boxed{ \text{Bias Repeatability} \rightarrow b_0^{MC} } \] \[ \boxed{ \text{Bias Instability} \rightarrow b(t) } \] \[ \boxed{ \text{Bandwidth} \rightarrow G(s) } \] \[ \boxed{ \text{Latency} \rightarrow \tau } \] \[ \boxed{ \text{Range} \rightarrow \text{Saturation Limits}. } \]

4.1.10.156 Sensor Specification to Kalman Filter

White output noise may define \(R\); bias-driving noise may define part of \(Q\); initial calibration uncertainty may define \(P_0\); alignment may belong in a calibration transform; and latency belongs in the timing model. Collapsing all specifications into one covariance term is physically inconsistent.

Not every datasheet number becomes \(R\).

Instead:

\[ \boxed{ \text{White Measurement Noise} \rightarrow R } \] \[ \boxed{ \text{Bias Random Walk} \rightarrow Q } \] \[ \boxed{ \text{Initial Bias Uncertainty} \rightarrow P_0 } \] \[ \boxed{ \text{Scale Factor / Alignment} \rightarrow \text{Calibration or State Augmentation} } \] \[ \boxed{ \text{Latency} \rightarrow \text{Timing Model} } \]

This distinction is extremely important.

4.1.10.157 Sensor Specification to Monte Carlo

A Monte Carlo campaign may classify specs as:

Fixed

\[ p=p_{nom} \]

Run-to-run

\[ p^{(j)} \sim \mathcal D \]

Time-varying

\[ p=p(t) \]

Conditional

\[ p=p(T,\omega,\rho,\ldots) \]

This produces realistic sensor uncertainty models.

4.1.10.158 Comparing Two Sensors Correctly

Two sensors should only be compared after normalizing:

units,
confidence level,
bandwidth,
output rate,
temperature,
dynamic range,
operating mode.

For example:

\[ \boxed{ 5\ \mu g/\sqrt{Hz} } \]

cannot be directly compared with

\[ \boxed{ 20\ \mu g\ RMS } \]

without knowing bandwidth.

4.1.10.159 Normalized Comparison

A good sensor trade table should convert all candidates to common metrics such as:

\[ \boxed{ \sigma_{sample} } \] \[ \boxed{ bias_{1\sigma} } \] \[ \boxed{ range } \] \[ \boxed{ latency } \] \[ \boxed{ mass } \] \[ \boxed{ power. } \]

This enables meaningful comparison.

4.1.10.160 Weighted Trade Study

Weighted scoring should come only after mandatory constraints are applied. A sensor that is light, cheap and accurate must still be rejected if it fails a hard radiation, range, timing, interface or qualification requirement.

A trade score can be represented as

\[ \boxed{ J = \sum_i w_i s_i } \]

where:

\(w_i\) = importance weight,
\(s_i\) = normalized sensor score.

But hard requirements should be treated as constraints, not merely weighted preferences.

4.1.10.161 Hard Constraints vs Trade Criteria

For example:

Hard constraints

\[ \boxed{ TID\ge TID_{req} } \] \[ \boxed{ range\ge range_{req} } \] \[ \boxed{ update\ rate\ge f_{req} } \]

Trade criteria

lower mass,
lower power,
lower cost,
better accuracy.

A sensor that fails a hard constraint should normally be eliminated regardless of weighted score.

4.1.10.162 Requirement Traceability

Every selected specification should trace back to a system requirement.

Conceptually:

\[ \boxed{ \text{Mission Requirement} \rightarrow \text{GNC Requirement} \rightarrow \text{Sensor Requirement} \rightarrow \text{Datasheet Verification}. } \]

This prevents arbitrary sensor selection.

4.1.10.163 Verification Method

A sensor requirement should identify how it will be verified:

analysis,
test,
inspection,
demonstration.

For example:

\[ \boxed{ \text{Mass} \rightarrow \text{Inspection} } \] \[ \boxed{ \text{Noise} \rightarrow \text{Test} } \] \[ \boxed{ \text{Navigation Impact} \rightarrow \text{Analysis / Monte Carlo}. } \]

4.1.10.164 Example Generic Gyro Comparison

Suppose two gyros have:

Gyro A

lower ARW,
better bias instability,
higher power,
larger mass.

Gyro B

higher ARW,
lower power,
lower mass.

The better choice depends on whether the mission is limited by:

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

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

There is no universally superior sensor.

4.1.10.165 Example Star-Tracker Comparison

A wide-FOV tracker may offer:

\[ \boxed{ \text{Higher Availability} } \]

while a narrower high-precision tracker may offer:

\[ \boxed{ \text{Better Accuracy}. } \]

Selection depends on mission attitude dynamics, exclusion geometry, redundancy, and pointing requirement.

4.1.10.166 Example GNSS Comparison

Receiver A may offer:

excellent PVT accuracy,
no carrier-phase raw output.

Receiver B may offer:

similar PVT,
pseudorange,
Doppler,
carrier phase.

For ordinary orbit determination, either may work.

For precision differential RPO:

\[ \boxed{ \text{Receiver B} } \]

may be far more valuable even if nominal standalone position accuracy is similar.

4.1.10.167 Example RPO Sensor Comparison

A camera may provide excellent bearing information but weak range observability.

A LiDAR may provide excellent range.

Thus:

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

can outperform either individually even when each has a worse headline accuracy in one dimension.

This shows why specification assessment must be system-level.

4.1.10.168 Spacecraft Sensor Selection Worksheet

For every candidate, record:

\[ \boxed{ \text{Performance} } \] \[ \boxed{ \text{Environment} } \] \[ \boxed{ \text{Electrical} } \] \[ \boxed{ \text{Mechanical} } \] \[ \boxed{ \text{Interface} } \] \[ \boxed{ \text{Qualification} } \] \[ \boxed{ \text{Heritage} } \] \[ \boxed{ \text{Procurement Risk}. } \]

This becomes the basis for 4.1.11 Sensor Selection for Space Missions.

4.1.10.169 Complete Datasheet Interpretation Flow

This should be treated as an iterative engineering loop. If Monte Carlo or hardware testing shows that navigation performance is not met, revisit the sensor requirement, candidate set, estimator assumptions or margins.

The complete workflow should be:

\[ \boxed{ \text{Mission Requirement} } \] \[ \downarrow \] \[ \boxed{ \text{Sensor Requirement} } \] \[ \downarrow \] \[ \boxed{ \text{Vendor Datasheet} } \] \[ \downarrow \] \[ \boxed{ \text{Interpret Units / Statistics / Test Conditions} } \] \[ \downarrow \] \[ \boxed{ \text{Normalize Candidate Sensors} } \] \[ \downarrow \] \[ \boxed{ \text{Convert to Simulation / Filter Parameters} } \] \[ \downarrow \] \[ \boxed{ \text{GNC Monte Carlo / Performance Analysis} } \] \[ \downarrow \] \[ \boxed{ \text{Select Sensor With Margin}. } \]

4.1.10.170 Complete Sensor Specification Categories

A complete spacecraft sensor specification should be reviewed under at least these categories:

\[ \boxed{ \text{Measurement Performance} } \] \[ \boxed{ \text{Noise and Stability} } \] \[ \boxed{ \text{Dynamics and Timing} } \] \[ \boxed{ \text{Geometry / FOV} } \] \[ \boxed{ \text{Environmental Compatibility} } \] \[ \boxed{ \text{Electrical Interface} } \] \[ \boxed{ \text{Mechanical Integration} } \] \[ \boxed{ \text{Reliability / Qualification} } \] \[ \boxed{ \text{SWaP} } \] \[ \boxed{ \text{Procurement / Heritage}. } \]

4.1.10.171 Final Engineering Perspective

The central lesson is:

\[ \boxed{ \text{Do Not Select a Sensor From One Headline Accuracy Number}. } \]

A sensor is a complete engineering system.

Its usefulness depends on:

\[ \boxed{ \text{Accuracy} + \text{Precision} + \text{Noise} + \text{Bias} + \text{Range} + \text{Bandwidth} + \text{Update Rate} + \text{Latency} } \]

together with

\[ \boxed{ \text{Temperature} + \text{Radiation} + \text{Vibration} + \text{Power} + \text{Mass} + \text{Interfaces} + \text{Qualification}. } \]

And for GNC specifically, the datasheet must ultimately be translated into:

\[ \boxed{ \text{Measurement Model} } \] \[ \boxed{ R } \] \[ \boxed{ Q } \] \[ \boxed{ P_0 } \] \[ \boxed{ \text{Saturation} } \] \[ \boxed{ \text{Latency} } \] \[ \boxed{ \text{Validity Logic} } \] \[ \boxed{ \text{Monte Carlo Uncertainty}. } \]

So the correct engineering chain is

\[ \boxed{ \text{Datasheet Specification} \rightarrow \text{Physical Meaning} \rightarrow \text{GNC Impact} \rightarrow \text{Simulation Parameter} \rightarrow \text{Requirement Verification}. } \]

This makes 4.1.10 Sensor Specifications the natural bridge between 4.1.9 Measurement Models and 4.1.11 Sensor Selection for Space Missions.