OTDR verdicts

How ruumica judges OTDR traces, why one direction is never enough for PASS, and how events are placed on the cable route.

An OTDR sends light pulses into a fibre and records what comes back. Its .sor file lists events along the fibre: splices, connectors and the fibre end, each with a distance and a loss. ruumica reads that file, judges every event against the project’s limits, and places each event on the cable route, so a failed splice can be found in the ground.

Limits come from the project

Each project has a splice loss limit, a connector loss limit and a reflectance limit. The defaults are 0.30 dB, 0.75 dB and −35.0 dB. Losses are compared in thousandths of a dB, the resolution of the file: a splice measured at exactly the limit passes. The limits used are recorded in the package (meta.rules), so the book says what a verdict was judged against.

Why one direction is never enough

A fusion splice between two slightly different fibres looks different from each end. From one end it can show a loss that is too high; from the other it can even show a gain. Only the average of both directions is the real loss. An apparent 0.35 dB can average to 0.10 dB; an apparent −0.10 dB can hide a 0.40 dB splice.

So ruumica gives three verdicts:

Verdict	Means
`PROVISIONAL`	Measured from one end only. Events over the limit are reported, but the trace cannot pass or fail yet.
`PASS`	Measured from both ends at the same wavelength; every event and the total loss are within the limits.
`FAIL`	Measured from both ends; at least one event or the total loss exceeds its limit.

Pairing two directions

Two traces form a pair when they are the same fibre of the same cable, measured from opposite ends at the same wavelength. ruumica pairs them automatically when both are ingested, in either order, or on request with asbuilt sor pair. It refuses a pair whose wavelengths differ or whose fibre lengths differ by more than 2 m plus 0.5 % of the length: those are not two views of one fibre.

An event seen from both ends is judged on its averaged loss. An event that shows up in only one direction is reported as unpaired and judged on that direction alone.

Group index

Distances in a .sor file depend on the group index (IOR) the OTDR was set to. If it was set wrong, every distance is off by the same proportion. You can give the correct value from the cable’s data sheet with --ior when ingesting; ruumica records that it did so (IOR_OVERRIDDEN). Re-ingesting without --ior returns to the file’s own value.

Placing events on the route

The fibre is longer than the route it lies along: it runs in a helix inside the cable, and spare cable is coiled in slack loops at nodes. ruumica rebuilds the fibre’s path from the cable’s route, its length factor and its slack loops, and walks along it:

an event inside a span is placed at its position along that span;
an event inside a slack loop is placed at the node where the loop is stored, not somewhere along a span.

The measured fibre end is then compared with the modelled one. If the fibre is far too long or too short for its route, a slack loop is missing or the route is wrong, and ruumica stops rather than absorb the difference (SLACK_FACTOR_OUT_OF_RANGE).

The raw file stays the evidence

The .sor file is never changed. It is stored under its SHA-256, delivered in the closeout package, and its verdict can be recomputed from it at any time. The closeout book prints every trace’s verdict next to the file’s fingerprint.