Week 06 · lesson

Calibration and Mounting Discipline

Calibration is not a magic reset button.

It is a process for connecting a sensor’s output to a known reference so the system can correct predictable error.

That means calibration only makes sense when the mounting, environment, reference condition, and procedure are themselves trustworthy.

Start with the error model

Imagine a fictional sensor reports:

reference angle: 0°
sensor reading: +4°

If that +4° offset appears consistently, the system may be dealing with bias.

A simple calibration could estimate the offset and compensate for it:

corrected reading = raw reading - estimated bias

But suppose the sensor is physically mounted 90° off from the orientation the software expects.

Subtracting 4° does not fix that.

The problem is not only numeric bias. The problem is orientation.

This is why calibration begins with the physical installation.

Mounting creates measurement conditions

A sensor can be electrically connected and still be poorly installed.

Mounting affects:

  • orientation;
  • vibration transmission;
  • magnetic environment;
  • airflow exposure;
  • field of view;
  • mechanical stability;
  • distance from heat or electrical-noise sources.

A camera aimed correctly in software but physically blocked by landing gear is not mission-ready. A magnetometer calibrated beside a strong magnetic source may produce a calibration result that is valid only for that bad environment.

Calibration has an expiration date

Not every calibration stays valid forever.

A calibration may need review after:

  • sensor replacement;
  • airframe repair;
  • payload relocation;
  • mounting change;
  • firmware or configuration change;
  • significant impact;
  • environmental change that affects the measurement method.

The important engineering idea is configuration dependency.

Calibration belongs to a specific sensor, mounted in a specific way, interpreted by a specific configuration.

Change the configuration and you may invalidate the evidence.

Worked case: rotated inertial sensor

A supplied simulator shows this behavior:

  • the aircraft model pitches forward;
  • the sensor display reports a strong roll response;
  • the numerical values are smooth and repeatable;
  • the sensor board diagram shows the module mounted 90° from the orientation assumed by software.

The sensor is not noisy.

The readings are not random.

The problem is an axis-mapping mismatch.

The correction belongs in the orientation/configuration model, not in a generic “recalibrate until it looks right” workflow.

Calibration versus validation

These two words are related but not identical.

Calibration adjusts or characterizes the relationship between sensor output and a reference.

Validation checks whether the resulting measurement is good enough for the intended use.

You can calibrate a sensor and still fail validation.

Example:

  • bias is corrected successfully;
  • but vibration causes large random noise during the mission condition;
  • therefore the measurement may still be unusable for the task.

That is why “calibration complete” is not the same as “sensor ready.”

Interference is a system problem

Some sensors are sensitive to the environment created by the aircraft itself.

A magnetometer can be affected by nearby current-carrying conductors, motors, or magnetic materials. A pressure sensor can be affected by airflow. A camera can be affected by vibration, glare, or blocked view. An inertial sensor can be affected by structural resonance.

The correct response is not to memorize one preferred mounting location.

Ask:

What physical phenomenon does this sensor respond to, and what else on the aircraft can create that phenomenon?

That question turns placement into engineering.

Use a calibration record

A useful calibration record should make the result reproducible.

For a fictional sensor, include:

FieldRecord
Sensor IDWhich device was calibrated?
Airframe/configurationWhich installation does the result belong to?
Mount orientationHow is the device aligned?
Reference conditionWhat known condition was used?
Observed offset/errorWhat pattern appeared before correction?
Calibration resultWhat parameter or transformation changed?
Validation checkWhat evidence showed improvement?
LimitationsWhat mission condition was not tested?

A note that says “calibrated — good” is almost useless six weeks later.

Worked comparison: before and after

Suppose a fictional range sensor is tested against a 1.00 m reference target.

Before adjustment:

1.08 m
1.07 m
1.08 m
1.07 m

After calibration:

1.01 m
1.00 m
1.01 m
1.00 m

The bias improved.

Now test at another reference distance:

reference: 3.00 m
sensor:    3.18 m

The sensor still has a scale or nonlinear error at longer range.

One-point calibration did not prove accuracy across the entire operating range.

That is a good example of why validation needs more than one convenient condition.

Your calibration-and-mounting analysis

Use a supplied sensor scenario and answer:

  1. What quantity is being measured?
  2. What mounting condition could distort it?
  3. What reference would you use for calibration?
  4. What error pattern do you expect: bias, noise, scale, orientation, or latency?
  5. What change would you make?
  6. What second condition would you use to validate the result?
  7. What configuration change would force you to repeat or review the calibration?

Misconception: calibration makes the sensor correct

Calibration improves the relationship between output and reference under the conditions you tested.

It does not eliminate:

  • future damage;
  • changing environment;
  • poor mounting;
  • electrical interference;
  • latency;
  • random noise;
  • blocked field of view;
  • software interpretation mistakes.

A mature sensor workflow keeps calibration records and still asks whether current evidence matches the mission.

The standard for this lesson

You should be able to look at a sensor problem and separate:

installation → calibration → validation → mission use

If those four stages collapse into one word—“setup”—troubleshooting becomes much harder than it needs to be.