Amazing_0619_1402x672

The Amazing OTDR

June 1, 2019
Part 1 of 4: Are You Getting the Most Out of Yours? Today fiber networks are the lifeblood of high-speed networking for virtually all applications. For most of us, what […]

Part 1 of 4: Are You Getting the Most Out of Yours?

Today fiber networks are the lifeblood of high-speed networking for virtually all applications. For most of us, what happens behind the scenes to turn them up and keep them operating efficiently is unseen. But for technicians, engineers, and others in the industry who live it every day, keeping networks up and running is a constant challenge. And the higher we push network speeds and resulting complexities, the more challenging it becomes.

With higher speeds comes increased sensitivity to more factors in the network, creating problems that earlier and slower networks could tolerate with little or no impact. But while continuous upgrades in technology have resulted in more dynamic and adapting networks today, the fundamental requirements for fiber performance remains mostly unchanged.

Establishing and maintaining networks requires accurate testing of the fiber infrastructure to ensure it can handle the system’s performance requirements and keep it operational. There is a wide range of tools that can accomplish these tasks, but there is arguably no other single instrument more important for testing and maintaining fiber networks than the Optical Time Domain Reflectometer (OTDR).

Determining the Health of Your Network

The OTDR has been around since the first fiber was installed and became commercially operational in the early 1980s. Today it is still the only optical test device that provides a visual view of the fiber link, providing a "fingerprint" of each fiber strand.

Figure 1. OTDR Trace = health certificate.

The information an OTDR provides is vast, including distance details from one end of the fiber to the other, performance of events in between and for the link overall. The information gained by testing with an OTDR is effectively equivalent to creating a health certificate for the specific fiber link tested. (See Figure 1.)

A properly configured OTDR operated by an experienced technician can capture the following important fiber network data:
• Length of the fiber link (meters, km, feet, or miles).
• Distance between spans and to events in the link (splices, connectors).
• Loss of connector interfaces and splices (dB).
• Loss of fiber sections between splices as a function of length (dB/km).
• Losses due to excess fiber bending (dB — varies w/ wavelength).
• Link Optical Return Loss (ORL) in dB.
• Optical Reflectance of each reflective event in the link (-dB).

In the preceding list of measurements, link loss and ORL are often officially documented using other traditional loss measurement methods. While OTDRs provide the same measurements using a different test method, the added benefit of using both methods is to establish a cross-correlation of test data. Since link loss and ORL performance is so important, cross-checking data results helps ensure tests are performed correctly and the resulting data is valid.

In addition to cross-checking results, OTDRs have an added value of enabling identification of mismatches between connected fibers. These occur commonly when multiple reels are spliced together. Mismatches can be due to splicing or connecting old to new, between different fiber manufacturers, or between different fiber types (e.g., G.652 to G.655).

Given the wide range of test data provided by the OTDR, its value should not be underestimated. As with most comprehensive tools, purchasing an OTDR is a substantial investment; and to get the most value for your money it is important to understand how to properly setup and operate the device.

Questions to Ask Before Purchasing

There are basic but critical questions important to answer before making a purchase to make sure you are buying one that meets your needs.
1. Are you using an OTDR that matches well with your applications?
2. Is your link single mode or multimode?
3. Based on your operating wavelengths, which wavelengths should be tested?
4. How much dynamic range is needed to optimally test your fibers?

Hopefully these considerations were included during the OTDR selection and purchase process, although sometimes companies realize later that they purchased testers that were not ideally suited for their applications. That issue goes beyond the scope of this article, so we will save that topic for another time.

For this series, we will assume you have purchased the OTDR in the configuration(s) that meet your requirements. But making the right purchase is just the beginning of getting the most out of the instrument. Too many users, even experienced ones, do not realize that if the OTDR is not setup or configured correctly for their specific parameters, then the data the OTDR provides can be compromised, resulting in limited or even inaccurate results. The cliché Garbage In, Garbage Out applies to high-tech OTDRs as well.

Uncovering Network Mysteries With an OTDR

Today we hear about more compact, "smarter" OTDRs. More recently, "automated" OTDR schematic-based interpretations have been touted as making OTDR testing as easy as pressing Go. These schematic-based tools are useful and provide a much easier interface for novice or occasional users. However, experience has shown they may be best suited for networks built "by the book" with few variations. But many network links out there produce unexpected results not easily interpreted by schematic-based software. Often these surprises become the rule in older or mixed networks, or as a result of multiple network changes over time.

Operators with link-testing experience understand that what you find is not always predictable — sometimes there are mysteries not so easily solved. Veteran OTDR users are likely acquainted with the surprise phenomena. But the best chance to uncover the reasons for these unexpected events is with well-trained users operating a properly configured OTDR for their particular link situation. That combination of knowledge and proper setup is key to accurately assessing links to ensure optimum operation.

Real World Examples: Don’t Let This Happen to You

An OTDR properly configured for the correct testing application and used by an experienced operator is an indispensable tool. But like any other tool, if an OTDR is not properly setup for the application being tested, the results can be misleading or inaccurate.

First let’s look at some real-world scenarios where the OTDR was not optimized and therefore failed to provide the needed information.

Scenario #1: OTDR to Link Connectivity
Example: Low power launch / High reflectance

A technician has completed acceptance testing on a pair of fibers in the field. He submits a report with an OTDR trace showing high span loss (dB/km) in the initial section of the fiber and a noisy trace near the fiber end. There is also high reflectance contributing to a large dead zone which masks most of the data from the first fiber section. The result is a poor launch (low power) which also reduces the dynamic range.

Figure 2. A poor trace.

These issues translate the following to the OTDR trace:
1. The higher reflectance at the start means we cannot clearly see the near end patch panel, and therefore we cannot measure the loss performance of that connection.
2. The high loss at the front end can also impact the trace downstream, causing it to be noisier. In especially longer links, we might be unable to display a clean, smooth trace; or we might have to use a longer pulse width to overcome the noise, which lessens our event clarity. (See Figure 2.)

Scenario #2: Optimizing OTDR Setups
Example: Mid-span — multiple closely spaced events

Figure 3. Mid Span Resolution.

A technician shooting between 2 data centers submits traces showing links that appear fine at the time, but engineers reviewing the trace data later see the mid-span (where trouble is suspected) with one wide reflection and >1dB loss. Engineers are aware of a patch through with about 150m of fiber in-between patches, but they are unable to view the 2 patch interfaces individually.

In this example, the trace might appear normal at first look or to the untrained eye. But to a skilled OTDR user, and based on the trace view and OTDR settings, a shorter pulse width could potentially separate and measure each of the mid-span panels. (See Figure 3.)

Scenario #3: File Management and Post Processing
Example: Bi-directional file naming inconsistencies

Four test teams are conducting bi-directional testing for multiple span acceptance tests. (Bi-directional means data in both directions are averaged to get the true loss data for the link.) However, management set tight work timelines to minimize testing time per job by each technician, so OTDR setups prior to testing at each span were rushed, and not all settings were checked.

Later, when engineers attempted to load the stored results during post testing, the A>B and B>A directional data files would not line up properly with each other. File names did not match, and pulse widths and display ranges were inconsistent. This resulted in bi-directional documentation being fragmented, inconsistent, and difficult to analyze. These issues required time-consuming manual file edits to be performed to enable traces to be processed correctly. Reported results were also inconsistent due to variations in pulse widths and display ranges between test traces.

Like this Article?

Subscribe to ISE magazine and start receiving your FREE monthly copy today!

Avoiding OTDR Issues

The problems in scenarios like those noted above could have been minimized or potentially avoided all-together IF best practices were implemented, and proper training and reasonable time allotments were enabled for test technicians. These practices would help to ensure correct and optimized setups and naming is implemented and validated consistently.

While the OTDR is a powerful and flexible tool, its effectiveness depends on the user’s ability and opportunity to set it up and use it properly. This series of fiber network articles will highlight the most critical aspects of OTDR operation and data collection, and it will explain how trained and savvy users can get the most from OTDR results. We will also examine problem scenarios like those introduced earlier in more detail, and explain how to avoid them.

Coming Up Next

Stay tuned for our next installment: "OTDR to Link Connectivity" — the first step in effective testing. We will explore why good connectivity is so important. We’ll look at how good connectivity and poor connectivity differ visually, and the most common reasons for each. And we will share best practices on how to optimize connectivity when using an OTDR and how this helps to get the best testing results.

The CFCE (Certified Fiber Characterization Engineer) is a 5-day boot camp and is recommended for technicians and engineers supporting high-speed (10G +) fiber networks. Advanced OTDR use and trace analysis are among key areas covered in the course. For more information, please visit http://www.fiberinsight.com/cfce.html.

Co-Authored with Carla Yount
Carla Yount is Co-Founder of Fiber Insight (Fi), and holds a master’s degree in information technology/software engineering. In addition to the usual financial and operational roles of her position, she is also sometimes the "B side" technician for Fi’s advanced testing projects. For more information, please email [email protected] or visit http://www.fiberinsight.com. Follow Fiber Insight on Twitter @fiberinsight.

About the Author

Tim Yount

Tim Yount has worked in the fiber industry for more than 30 years. He is Co-Founder of Fiber Insight (Fi), which specializes in fiber network infrastructure testing for advanced network qualification. Fi is also licensed by Optical Technology Training (OTT) to offer their globally recognized certification courses in advanced fiber testing (CFCE) and network design (CONA). For more information, please email [email protected] or visit http://www.fiberinsight.com. Follow Fiber Insight on Twitter @fiberinsight. Follow Tim Yount on Twitter @y_tyount404.