Automated OTDRs take on 21st-century fiber testing
Frank Buchanan / Agilent Technologies
Automated OTDR processes facilitate quick and accurate collection, checking, organization, and analysis of fiber trace data.
Over the last 20 years, the optical time-domain reflectometer (OTDR) has established itself as the primary testing tool for installing, commissioning, maintaining, and repairing a singlemode fiber-optic cable network. Design enhancements in dynamic range and automated features have resulted in speed and accuracy improvements in all these facets of OTDR testing. Arguably, however, the area of testing that has benefited the most from these enhancements is the commissioning of fiber-optic cables.
With high-dynamic-range OTDRs and sophisticated software that offers batch processing, fiber commissioning takes a fraction of the time required by earlier technologies.
Not long ago, a 24-fiber cable was the maximum fiber count deployed in optical communication networks, and commissioning these relatively low-fiber-count networks presented a relatively easy task. A fiber-optic technician acquired trace data of the 24 fibers at one or two wavelengths and, occasionally, took trace data from each fiber in both directions. The trace data taken from both directions was averaged to normalize the effects caused by backscattering phenomena (gainers) common to singlemode OTDR testing. The resulting information was printed and gathered in some type of binder or notebook and given to the design engineer for final approval.
To accommodate the ever-increasing bandwidth demands of today, 144-fiber cables are commonly deployed with 432-fiber cables in some areas. So, how does the fiber-optic test technician of the 21st century quickly and accurately collect, analyze, organize, and store the literally hundreds of fiber traces that are taken when commissioning these high-fiber-count networks? The answer lies in the OTDR, which can provide high-speed, fully automated data acquisition, in combination with a powerful but easy-to-use software package that quickly processes and organizes the trace data.
The ability to quickly acquire clean trace data is a strong function of how long it takes the OTDR to average the data. And, generally speaking, the higher the dynamic range of the OTDR the less time needed to average the trace data. The key lies in signal-to-noise ratio, which is common to almost all measurement instruments.
Using a hypothetical example, assume it takes 3 min to average a trace of a 100-km fiber network using a 35-dB-dynamic-range OTDR. Empirical data has shown that a 45-dB-dynamic-range OTDR can achieve the same trace results on the same 100-km fiber after averaging for only 20 seconds. For example, when testing a 144-fiber cable at two wavelengths and from both directions, the OTDR measurement time is reduced from 28.8 to 3.2 hours, almost an order-of-magnitude time savings.
Automated acquisition and documentation of fiber cable data speeds processing in modern multifiber environments.
In addition to providing high-dynamic-range capability, the OTDR must be able to acquire and check multiple fiber trace data automatically. This functionality is similar to running a macro in a computer in which a test is performed repeatedly in a loop. Multifiber test automation is imperative because, for example, 576 traces will be generated when commissioning a 144-fiber cable network.
Procedurally, the first task in setting up an automated multifiber test is to optimize and store a set of test parameters, such as pulsewidth and range, which will be used for trace-data acquisition. Any one of the 144 fibers can be chosen as a representative of the other fibers for optimization of these parameters. However, care should be taken to choose a fiber that does not contain obvious flaws, such as grossly large fusion splices, cracks, or inordinately large fiber attenuation.
Initial trace data can be taken on the representative fiber by setting the OTDR in an automatic pulsewidth and range mode. This allows the technician to acquire initial trace data without knowing the exact features of the network. Once a trace has been acquired in this mode, the technician can then make the appropriate pulsewidth and range adjustments to better suit the testing requirements.
The next task in setting up an automated multifiber test is to load limits into a "trace-checker" function of the OTDR that will check events in each trace for compliance to a predetermined set of specifications. For example, a limit of 0.05 dB could be set for fusion splices and a limit of 30 dB for total network loss. When the trace checker is engaged, it will search for and flag any fusion splices that exceed 0.05 dB. Similarly, it will also search for and flag any total network losses that exceed 30 dB. Limits for other features such as reflections, fiber attenuation, and network length also could be set.
Once the data-acquisition parameters have been determined and the trace-checker limits loaded, the test can be saved as a "SETtings" file. For example, a test at 1310 nm could be called "13.SET." Similarly, a 1550-nm test could be called "15.SET."
Multifiber test and auto-saving
Now that the test parameters "13.SET" and "15.SET" are defined and saved, they can be loaded in a multifiber test mode (macro) that will automatically sequence from 1310-nm testing to 1550-nm testing. The final procedure needed to complete the setup for automated testing is to designate fiber file names for each wavelength and direction. Proper selection of the file name will provide the technician with information regarding the wavelength being tested, the direction the trace is being shot, and, most important, the number of the fiber under test. Proper placement of the fiber number in the file name will allow the multifiber test macro to auto-increment the fiber count. For example, the 1310-nm test on the first fiber could be called 13ABtest.001. The "AB" designation would indicate the direction from which the trace data are being taken. Similarly, the 1550-nm test could be called 15ABtest.001. Obviously, traces taken from the other end would have the designation 13BAtest.001 and 15BAtest.001
Once these tests are loaded into the multifiber test macro and the initial file names are assigned, the test technician can begin the tests. The patch cord from the OTDR is connected to the first fiber under test. The OTDR selects the 1310-nm test first, acquires the trace data, and checks the trace to see if the trace-checker limits have been exceeded. If they have not, the OTDR automatically stores the data and switches to the 1550-nm test. As before, the trace data is acquired, checked, and stored, assuming no limits are exceeded.
Appropriate software makes it easy to organize trace data and perform competitive tasks such as two-way batch averaging and batch printing.
At this point, the multifiber test has completed one loop and is waiting for a manual prompt to start the macro again. The technician now can move the patch cord to the second fiber and re-engage the multifiber test macro. After each wavelength is tested in the second loop, the OTDR will automatically increment the trace file names to 13ABtest.002 and 15ABtest.002. This procedure will continue until files 13ABtest.144 and 15ABtest.144 are reached. Data taken from direction "B" to "A" can be taken and stored as described above.
With 576 traces acquired, checked, and stored, the data-acquisition phase of the commissioning task is complete. Now, the documentation phase begins. First, it is important to organize the trace data in such a way that it facilitates post-processing. A good Windows-based trace-analysis software program will allow the technician to structure the trace files as folders in a directory tree that corresponds to the physical attributes of the fiber cable.
For example, the highest-level folder in the directory tree could be the cable. The next level could contain folders representing, for example, 12 loose buffer tubes in a 144-fiber cable. These folders could be labeled by their color and could also indicate the direction from which the trace was shot, "A," for example. Therefore, there could be 12 folders for direction "A" and 12 folders for direction "B." The next level could contain folders representing each of 12 fibers per loose buffer tube. Within each of the fiber folders could be the trace data taken at 1310 and 1550 nm. The result of the directory tree is a highly organized project that is logical and easy to understand. This file-management tree could be set to accommodate virtually any type of fiber cable.
Once the data is organized, it is easier to perform some final, important post-processing tasks. The first task is to label all the traces with the appropriate administrative data such as the project name, cable name, network origination and destination names, and test technician name. Because the wavelength of the tests is already stored with the trace files, only the origination and destination names change for the 576 traces. Therefore, 288 traces will share the same administrative data. These files could come from the 12 loose-tube directories under direction "A," for example. Rather than type this data into each trace file separately, the technician can use one trace as a template and then "batch-process" the same administrative data to the remaining 287 traces by pressing a single button.
The next task is to average the data of the 288 traces taken from "A" to "B" with the data of the 288 traces taken from "B" to "A." This could be a very time-consuming venture if each trace had to be manually matched and processed with the corresponding trace shot from the other direction. As with the administrative data, however, the software performs a totally automated two-way average batch process with the press of a button. Not only is the two-way average batch-processed, but the software automatically creates a separate directory that organizes the resulting two-way trace data in logically labeled folders.
Once the administrative and two-way-average data are processed, they are ready to be printed. As with the previous two functions, the software is capable of printing all the data in a batch process. This printing process could be performed overnight for convenience.
Frank Buchanan is an applications engineer at Agilent Technologies (Colorado Springs, CO).
This article originally appeared in the June 2000 issue of Laser Focus World, a sister publication.