Name: Covenant Systems
Address: US
Price range: $$

Question 1

Has this been tested against a real OTDR file?

Accepted Answer

Not yet, and that is stated on the tool itself rather than buried here. The reader was written from the Telcordia SR-4731 specification. Its block navigation is verified by round-trip tests — a file is written with known contents, read back, and every field compared — and its measurements are verified against traces whose true splice losses, attenuation and break location are known by construction, where it recovers a 0.062 dB splice as 0.062 dB and a 0.191 dB/km fibre as 0.191 dB/km. But every one of those files was written by us, from the same reading of the same document, so they agree with the reader by construction. What that cannot settle is whether the scaling constants match what instruments actually write. Send us a trace from any OTDR and the caveat comes off — a real SEL-451 record broke four assumptions in our relay parser that no amount of reading the format description had caught, and we expect no better here.

Question 2

What is a gainer, and why does a splice show negative loss?

Accepted Answer

Nothing is producing light. An OTDR does not measure loss directly — it infers it from how much light comes back, and that depends on the fibre's backscatter coefficient as well as on the splice. Join two fibres whose coefficients differ slightly and the join reads high from one end and low from the other, by exactly the same amount. Where that difference is larger than the splice's actual loss, the reading goes negative and the splice appears to be a source. It is not: it is one direction of a two-direction measurement. The true loss is the average of the two, and half the difference between them is the mismatch, which is a property of the glass rather than of the splice. This reader detects steps in both directions rather than only losses, which matters because on a real span roughly half the splices come out as gainers in one direction — a detector that only looked for losses would go quiet across half a reverse trace and report nothing where the instrument reported events.

Question 3

How does the bidirectional averaging work?

Accepted Answer

Load the A-to-B trace, then load the B-to-A trace beside it. The reverse trace's distances are mirrored about the span length so both are expressed from the A end, events are matched within sixty metres, and each pair is averaged. The two directions stay in their own columns and the true loss sits between them, because the point is not to replace two numbers with one — it is to show how far apart they were. A pair agreeing to a thousandth and a pair disagreeing by a tenth both average to something; only one of them is worth acting on without asking why. If the two traces disagree about the span length by more than 250 m they are refused rather than averaged, because at that point they are not the same fibre measured twice and averaging them would produce a confident number about nothing.

Question 4

Why re-measure events the instrument already measured?

Accepted Answer

Because an OTDR's automatic event finder is a vendor's judgement call about thresholds, not a fact about the fibre. Two instruments shooting the same span routinely disagree about whether a 0.09 dB splice is an event at all, and about what it cost when they agree it is one. So this reader does its own pass over the backscatter samples and shows both answers side by side, never merged. Where they agree, you have two independent measurements. Where they disagree — and on a real trace they will — that disagreement is the most useful thing on the screen, and any tool that hid it behind one number would be making the choice of which vendor to believe on your behalf.

Question 5

How is splice loss measured here?

Accepted Answer

By least squares, which is the only method offered. Clear fibre is fitted either side of the event, both fits are projected to it, and the difference between them is the loss. The two-point method — read the trace just before and just after — is faster and reads whatever noise happens to sit on the two points it picks. The windows are a hundred metres of fibre either side where there is that much clear fibre available, shortened when there is not, and they are never allowed to cross a reflection or the end of the fibre: a fit that straddles a connector is not measuring fibre, and projecting it produces a step of several decibels at a point where nothing happened.

Question 6

How does it decide something is an event rather than noise?

Accepted Answer

By comparing the step against its own uncertainty, not against a fixed number of decibels. Each fit yields a residual spread — the trace noise, measured rather than assumed — and from that and the fit geometry comes a standard error on the projected step. An event has to clear five of those. That threshold is chosen for the fact that a trace offers thousands of candidate positions, so a level respectable for a single measurement fires constantly across a whole record. The first version of this used a fixed 0.04 dB and invented two dozen splices out of noise on a trace that had four; it is caught by a test that now runs on every build. Under-calling a marginal splice is recoverable, because the trace is still on screen and the instrument's own table is beside it. Sending a crew to dig up a handhole that has nothing wrong with it is not.

Question 7

What is the launch dead zone, and why is nothing measured in it?

Accepted Answer

The front-panel connector sits at the origin and reflects hard, and the receiver takes about a pulse width to recover from it. Inside that stretch the trace is the instrument looking at its own reflection, not at your fibre, so no independent measurement is possible there and this reader does not attempt one — it reports where the dead zone ends and marks any event the instrument listed inside it as unmatched for that reason rather than as contradicted. The field answer is a launch cable: a spool of known fibre ahead of the span under test, so the near-end connector you actually care about sits out in clear trace instead of underneath the reflection.

Question 8

What are the two markers for?

Accepted Answer

They are how an OTDR is actually read. Every real question asked of a trace — how far to the break, what did that splice cost, is this section running high — is answered by putting two markers down and reading the distance, loss and slope between them. Click sets A, shift-click sets B. That reading is taken from the raw samples rather than from a fit, which is deliberate: it is the number you would get standing at the instrument, and having it beside the least-squares figures makes it obvious when a two-point reading has landed on noise.

Question 9

Which blocks does it read?

Accepted Answer

The map, the general parameters, the supplier parameters, the fixed parameters, the key events and the data points. Anything else in the file — vendor-proprietary blocks, and the checksum — is listed with its size in the File tab and skipped intact rather than guessed at. Files written to the original Bellcore issue, which predate the block map, are refused outright: without a map there is no way to know where one block ends and the next begins except by assuming a layout, and assuming a layout is exactly what this reader is built to avoid. Every field is bounds-checked against its own block, so a short or truncated file comes back with missing fields and a warning saying which, never with whatever bytes happened to follow.

Question 10

Why does a field say “not in this file” instead of showing a sensible default?

Accepted Answer

Because a fibre acceptance test is an argument about tenths of a decibel, and a plausible-looking substitute for a number the file never carried is the worst thing a reader can produce. A wavelength that is absent comes back as absent, not as 1550. If the group index is missing, distances are not scaled and are not shown — an unscaled distance drawn as though it were metres would send someone to the wrong handhole. Every hole in the data is visible as a hole.

Question 11

Where do the acceptance limits come from?

Accepted Answer

They are fields, not constants, because the limit that applies to your span is in your specification or your contract. The defaults are common utility figures — 0.10 dB at a fusion splice, 0.50 dB at a connector, reflectance no worse than −40 dB, 0.25 dB/km at 1550 nm — and they are offered as a starting point rather than as a standard. The span loss budget deliberately starts blank: it comes from the link design, from launch power and receiver sensitivity and the margin the system was engineered with, so any figure invented here would be judged against nothing at all.

Question 12

Does anything I open get uploaded?

Accepted Answer

No. The file is read with the browser's own file API and parsed in local JavaScript; the analysis, the plot and the CSV export all run on your machine. Nothing about the trace is transmitted — not the cable ID, not the locations, not a distance, not a loss. That matters more here than it looks: a trace names two ends of a real route and says exactly where the weak splice on it is, which is commercially sensitive and, on a utility span, a map to something worth protecting. This page carries the same anonymous usage analytics as the rest of the site, which records that a file was opened and whether the reader coped with it. It cannot see the file.

OTDR .SOR Reader

Clean span, accepted

The example traces are written as real .SOR files, then read back through the same parser

Need it to do more?

How to read it

What each feature means

Questions