Request an intervention

Operational notes Testing

OTDR Certification: How to Actually Read a Test Report

4 min read

OTDR instrument with a measurement trace on screen, connected to a launch coil
The trace always tells the truth. The PDF, not always.

The OTDR report is often the last PDF of the job: it arrives with the invoice, gets signed, and is filed away unread. Yet it is the only document that says whether the network you paid for actually works — and whether it will still work in five years. You don’t need to be a fibre technician to read it: you just need to know what it must contain, and which omissions are a warning sign.

Tier 1 and tier 2: two different tests.

The tier 1 test (or “basic”) measures the overall insertion loss of the link using a light source and power meter, plus length and polarity. It answers a single question: does the run stay within the optical budget? It’s the reference measurement for pass/fail, but it’s blind: if the loss is too high, it doesn’t say where or why.

The tier 2 test (or “extended”) adds the OTDR trace: an event-by-event snapshot of the run — every connector, every splice, every anomalous bend, with its position and its loss. The two levels aren’t alternatives: the OTDR characterises, the power measurement certifies the total loss. A serious specification requires both on the runs that matter. If you were only handed one of the two, ask why.

Events and dead zones.

The OTDR launches light pulses and measures what comes back. Two families of events appear on the trace: reflective events (connectors, mechanical splices, breaks with a clean face), which show up as spikes, and non-reflective events (fusion splices, tight bends), which show up as loss steps with no spike.

After every reflective event the instrument is momentarily “blinded”: this is the dead zone, and it has two measures — the minimum distance needed to distinguish a second event, and the one needed to measure its attenuation again. The practical consequence: the first and last connector of the run cannot be measured without a launch coil and a tail coil. A report without stated coils has simply skipped the two points where problems are most frequent.

Bidirectional measurement is not a nicety.

A splice measured in one direction only can even come out “negative”: an apparent gain, which is physically impossible. This happens when the two spliced fibres have different backscatter coefficients: the OTDR, which infers loss from backscattered light, is fooled. The true value of every splice is the average of the measurements taken in both directions, as specified by ITU-T G.650.3.

A useful corollary: a unidirectional report showing “gainer” splices is documentary proof that no one averaged the readings. And the per-splice loss values written into the specification — as we discussed in our note on splicing — can only be verified this way.

The tricks behind poorly made reports.

It is almost never bad faith; it is almost always haste. But the result is the same. The recurring defects:

  • A single wavelength. At 1550 nm tight bends show up; at 1310 nm they often don’t: you need both.
  • A single direction. See above: per-splice values are unreliable.
  • No launch coil. The first connector simply doesn’t exist in the report.
  • Generous pass/fail thresholds. At 0.5 dB per splice, everything passes; the thresholds must be those set out in the specification, not the instrument’s factory defaults.
  • Wrong refractive index. The distances don’t add up, and the events no longer match the as-built.
  • Pulse width too long for short runs. Nearby events merge into one, and some connectors disappear.
  • Unrecognised ghost events. Multiple reflections that appear as events that don’t actually exist: an attentive operator flags them, a rushed report leaves them in.
  • PDF only, no native traces. Without the measurement files (the .sor files), no one can re-verify anything, today or in five years.

The client’s checklist.

Before signing off, verify that the report contains:

  1. the native traces (.sor or equivalent), not just the PDF;
  2. measurements at two wavelengths (1310 and 1550 nm) and in two directions, with the per-splice average;
  3. launch and tail coils stated, with their length;
  4. explicit pass/fail thresholds consistent with the specification;
  5. the complete event table: per-splice loss, per-connector reflectance, distances;
  6. instrument, calibration date, operator and date of the measurement;
  7. correspondence with the as-built: every event on the trace must have a name on the diagram.

And three questions to ask whoever hands it to you: which direction did you measure in? With what thresholds? Can I have the native files? If the answer to the third is no, you already have the answer to the first two.

The bottom line.

A well-made OTDR report costs only slightly more than a poorly made one: the difference is method, not time. That’s why we certify every run bidirectionally and always hand over the native traces — on a backbone as much as in a data centre, where every tenth of a dB counts.

Do you have a test report that needs checking, or a specification to write before your next tender? Get in touch: reviewing a certification together takes less than an hour.

Sources