A multi-channel optical fiber link automated test system

Abstract

This application discloses an automated testing system for multi-channel optical fiber links, including a handheld testing platform and an OTDR testing device. The handheld testing platform has a human-machine interface screen and connects to the OTDR testing device via a communication interface for issuing control commands and receiving and processing test data. The OTDR testing device includes a main control module, an optical switch module, an OTDR optical transceiver module, and an MPO interface. The main control module parses control commands and coordinates the operation of each functional module. Under the control of the main control module, the optical switch module switches the optical signal to the target optical fiber link. The OTDR optical transceiver module sends test optical pulses to the target optical fiber link, receives the returned optical signals, and converts them into test data in the form of electrical signals. The MPO interface connects to an external multi-core MPO optical cable via an MPO connector, establishing an optical path connection between the optical switch module and each fiber core. This technical solution effectively improves the problems of existing OTDR equipment's inability to efficiently test multi-core MPO optical cables and the low efficiency and cumbersome operation of manual core-by-core testing.

Description

Technical Field

[0001] This application relates to the field of optical transmission technology, and more specifically, to an automated testing system for multi-fiber optic links. Background Technology

[0002] An optical time domain reflectometer (OTDR) is a crucial tool for testing and diagnosing fiber optic networks. By emitting optical pulses into the fiber and analyzing the Rayleigh and Fresnel reflections returning from various points along the fiber link, an OTDR can measure fiber length, locate fault points, and assess connection quality. OTDRs are indispensable testing instruments in the construction, maintenance, and troubleshooting of fiber optic communication networks.

[0003] Traditional OTDR testing typically requires manual testing of each fiber optic link individually. For multi-core optical cables, testers need to repeatedly plug and unplug fibers to test each core, which is inefficient and prone to errors. With the development of 5G and big data, the scale of data center construction is expanding rapidly. MPO (Multi-fiber Push-On) connectors, with their advantages of saving space and improving construction efficiency, have been widely used in high-speed interconnect scenarios such as 40G / 100G. MPO connectors can integrate 12, 16, 24, or even more optical fibers within a single interface, significantly increasing the density of fiber optic links.

[0004] However, the widespread adoption of MPO optical cables has also brought new challenges to fiber optic testing. Existing OTDR products are mainly designed for testing single-core fibers and cannot be directly adapted to the multi-core structure of MPO interfaces. When testing MPO optical cables, field technicians typically need to use fan-out branch cables to bring out each fiber core from the MPO interface one by one and then connect them to a traditional OTDR for core-by-core testing. This testing method is cumbersome, time-consuming, and the frequent plugging and unplugging of branch cables may introduce additional losses and testing errors, making it difficult to meet the requirements for testing efficiency and accuracy in scenarios such as data centers. Summary of the Invention

[0005] The purpose of this application is to provide an automated testing system for multi-fiber links, which aims to improve the problems of existing OTDR equipment being unable to efficiently test multi-core MPO optical cables, as well as the low efficiency and cumbersome operation of manual core-by-core testing.

[0006] To achieve this objective, embodiments of this application provide an automated testing system for multi-channel fiber optic links. The automated testing system includes a handheld testing platform and an OTDR testing device, wherein... The handheld testing platform has a human-computer interaction screen, which is set to receive test parameters configured by the user, and connect to the OTDR testing device through a communication interface to send control commands to the OTDR testing device, and receive and process the test data returned by the OTDR testing device to display the corresponding test results. The OTDR testing device includes a main control module, an optical switch module, an OTDR optical transceiver module, and an MPO interface. The main control module is configured to receive and parse control commands through the communication interface to coordinate and control the operation of various functional modules within the OTDR testing device according to the parsed commands, and to transmit the collected test data back to the handheld testing platform through the communication interface. The optical switch module is connected to the main control module and is configured to switch the optical signal to the target optical fiber link under the control of the main control module. The OTDR optical transceiver module is connected to both the main control module and the optical switch module, and is configured to send test optical pulses to the target optical fiber link currently switched by the optical switch module under the control of the main control module, and receive the optical signals returned from the target optical fiber link, convert them into test data in the form of electrical signals, and transmit them back to the main control module. The MPO interface is connected to the optical switch module and is configured to interface with an external multi-core MPO optical cable through an MPO connector to establish an optical path connection between the optical switch module and each fiber core in the multi-core MPO optical cable.

[0007] Optionally, in some embodiments of this application, the handheld testing platform is a testing platform developed based on at least one of the Android system, iOS system, and HarmonyOS system; and / or, The communication interface is any one of USB, Bluetooth, WiFi, or Ethernet interfaces, and the handheld test platform and the OTDR test device exchange data through the corresponding communication protocol.

[0008] Optionally, in some embodiments of this application, the optical switch module is a 1×N optical switch, where N is a positive integer greater than or equal to 2. The common terminal of the optical switch module is connected to the OTDR optical transceiver module, and the N output terminals of the optical switch module are respectively connected to the N optical fiber links in the MPO interface. The N optical fiber links in the MPO interface are also connected to the N fiber cores of the multi-core MPO optical cable through MPO connectors, so that under the control of the main control module, the optical path connecting the OTDR optical transceiver module and each fiber core in the multi-core MPO optical cable can be switched one by one, thereby realizing the one-by-one testing of each fiber core in the multi-core MPO optical cable.

[0009] Optionally, in some embodiments of this application, the optical switch module is any one of a 1×12-channel optical switch, a 1×16-channel optical switch, and a 1×24-channel optical switch, to adapt to the testing of 12-core, 16-core, or 24-core multi-core MPO optical cables; or, The optical switch module is a cascaded multi-channel optical switch to adapt to testing of multi-core MPO optical cables with more than 24 cores.

[0010] Optionally, in some embodiments of this application, the OTDR testing device further includes a wavelength selection module, which is connected to the main control module and the OTDR optical transceiver module respectively, and is configured to select a target wavelength from a variety of preset test wavelengths under the control of the main control module, so that the OTDR optical transceiver module emits a test light pulse corresponding to the target wavelength; the variety of preset test wavelengths are a combination of single-mode test wavelengths or a combination of multi-mode test wavelengths.

[0011] Optionally, in some embodiments of this application, the single-mode test wavelength combination includes a 1310nm wavelength and a 1550nm wavelength, and the multi-mode test wavelength combination includes an 850nm wavelength and a 1300nm wavelength; and / or, The wavelength selection module is a tunable filter or a wavelength splitter.

[0012] Optionally, in some embodiments of this application, the OTDR optical transceiver module includes a laser, a photodetector, a wavelength division multiplexer, and a signal processing unit, wherein, The laser is configured to generate the test light pulse under the control of the main control module. The wavelength division multiplexer is configured to couple the test optical pulse to the current channel of the optical switch module and separate the optical signal returned from the target optical fiber link to the photodetector; The photodetector is configured to convert the received optical signal into an analog electrical signal; The signal processing unit is configured to amplify, filter, and perform analog-to-digital conversion on the analog electrical signal to generate the digitized test data.

[0013] Optionally, in some embodiments of this application, the handheld testing platform further includes a parameter configuration module, a command issuance module, a data receiving module, a data processing module, and a result display module, wherein, The parameter configuration module is configured to provide a graphical test parameter configuration interface through the human-computer interaction screen, and to receive and verify the rationality of the test parameters configured by the user. The instruction issuing module is configured to generate control instructions conforming to the communication protocol format based on the test parameters, and issue them to the OTDR test device through the communication interface. The data receiving module is configured to receive test data returned by the OTDR testing device through the communication interface, and to parse and verify the test data. The data processing module is configured to perform event detection and link analysis on the parsed and verified test data, and generate test results that include at least fiber length, connector loss, reflection events, and link attenuation. The result display module is configured to visualize the test results on the human-computer interaction screen in a preset display format.

[0014] Optionally, in some embodiments of this application, the test parameters include at least one of the following: fiber core channel selection parameters, test wavelength selection parameters, pulse width parameters, test range parameters, and test duration parameters; and / or, The preset display format includes at least one of line graphs, event lists, and link overview graphs.

[0015] Optionally, in some embodiments of this application, the handheld testing platform further includes a channel status monitoring module. This module is configured to acquire the currently tested fiber channel number in real time during the channel switching process of the optical switch module and display the current testing progress on the human-machine interface screen; and / or, The handheld testing platform further includes a storage module, which is configured to store the test parameters, the test data, and the test results; and / or, The handheld testing platform also includes a wireless communication module, which connects the handheld testing platform to external devices to enable remote control and data uploading.

[0016] Optionally, in some embodiments of this application, the control commands include channel switching commands, test start commands, and test parameter configuration commands; The main control module controls the optical switch module to switch to the target channel according to the channel switching command and a preset channel switching logic; The main control module controls the OTDR optical transceiver module to emit the test optical pulse according to the test start command; The main control module configures the test parameters of the OTDR optical transceiver module according to the test parameter configuration instructions.

[0017] Optionally, in some embodiments of this application, the channel switching logic includes at least one of sequential scanning, custom channel, and breakpoint continuation testing, wherein... The sequential scanning method is set to switch and connect each channel corresponding to the optical switch module one by one in ascending order of fiber core number; The custom channel mode is set to switch to the channel corresponding to one or more target fiber cores selected by the user in the test parameter configuration interface; The breakpoint continuation test method is configured to record the channel corresponding to the currently completed fiber core during the test, and when the test is restarted after an interruption, continue the test from the channel corresponding to the next untested fiber core.

[0018] Optionally, in some embodiments of this application, the OTDR testing device is a pluggable module with an independent housing package, the handheld testing platform is provided with a mounting slot adapted to the shape of the OTDR testing device, and the communication interface is exposed in the mounting slot and on the outer surface of the OTDR testing device respectively. The OTDR testing device is detachably installed in the mounting slot and is physically and electrically connected to the handheld testing platform through the communication interface.

[0019] The automated testing system for multi-fiber links provided in this application, through the aforementioned structural configuration, highly integrates a handheld testing platform, an OTDR optical transceiver module, and an optical switch module. It features an MPO interface that directly connects to an external multi-core MPO optical cable. The handheld testing platform controls the optical switch module to automatically switch between the individual cores of the multi-core MPO cable, achieving automated, core-by-core testing of each fiber. Compared to existing technologies that require manual testing using fan-out branch cables, this automated testing system for multi-fiber links eliminates the need for additional branch cables. It allows for direct connection to the multi-core MPO cable, and the testing and data analysis of each core can be completed without manual intervention, significantly improving the testing efficiency and accuracy of multi-core fiber links and reducing maintenance costs. Therefore, this technical solution effectively addresses the problems of existing OTDR equipment's inefficient testing of multi-core MPO optical cables and the low efficiency and cumbersome operation of manual core-by-core testing. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] The structures, proportions, sizes, etc., shown in the accompanying drawings are only for the purpose of assisting those skilled in the art in understanding and reading the content disclosed in the specification, and are not intended to limit the implementation conditions of this application. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportions, or adjustments to the size should still fall within the scope of the technical content disclosed in this application, provided that they do not affect the effects and purposes that this application can produce.

[0022] Figure 1 This is a schematic diagram of the structure of the automated testing system for multi-channel fiber optic links according to an embodiment of this application; Figure 2 for Figure 1 The diagram shows the split structure of the automated testing system for multi-fiber links. Figure 3 for Figure 1 Another structural diagram of the automated testing system for multi-fiber optic links shown. Figure 4 for Figure 1 The diagram shows the optoelectronic connection block diagram of the OTDR test device in the automated test system for multi-fiber links. In the diagram, the dashed lines represent optical signal connections, and the solid lines represent electrical signal connections. Figure 5 for Figure 1 The diagram shows the electrical connection of the handheld test platform of the automated multi-fiber link test system.

[0023] Illustration: 1. Multi-channel fiber optic link automated testing system; 10. Handheld testing platform; 11. Human-machine interface screen; 111. Parameter configuration module; 112. Command issuance module; 113. Data receiving module; 114. Data processing module; 115. Result display module; 116. Channel status monitoring module; 117. Storage module; 118. Wireless communication module; 12. Installation slot; 20. OTDR testing device; 21. Main control module; 22. Optical switch module; 23. OTDR optical transceiver module; 231. Laser; 232. Photodetector; 233. Wavelength division multiplexer; 234. Signal processing unit; 24. MPO interface; 25. Wavelength selection module; 30. Communication interface. Detailed Implementation

[0024] To make the inventive objectives, features, and advantages of this application more apparent and understandable, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] In the description of this application, it should be understood that the terms "upper," "lower," "top," "bottom," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. It should be noted that when a component is considered to be "connected" to another component, it can be directly connected to the other component or there may be a component centrally located at the same time.

[0026] The technical solution of this application will be further described below with reference to the accompanying drawings and specific embodiments.

[0027] Please see Figures 1 to 5As shown, in one embodiment, this application provides a multi-channel fiber optic link automated testing system 1. This system specifically includes a handheld testing platform 10 and an OTDR testing device 20. The handheld testing platform 10 has a human-machine interface screen 11, configured to receive user-configured test parameters and connect to the OTDR testing device 20 via a communication interface 30. It sends control commands to the OTDR testing device 20 and receives and processes test data returned by the OTDR testing device 20 to display the corresponding test results. The OTDR testing device 20 includes a main control module 21, an optical switch module 22, an OTDR optical transceiver module 23, and an MPO interface 24. The main control module 21 is configured to receive and parse control commands via the communication interface 30, coordinate the operation of various functional modules within the OTDR testing device 20 according to the parsed commands, and transmit the collected test data back to the handheld testing platform 10 via the communication interface 30. The optical switch module 22 is connected to the main control module 21 and is configured to switch the optical signal to the target fiber optic link under the control of the main control module 21. The OTDR optical transceiver module 23 is connected to both the main control module 21 and the optical switch module 22. Under the control of the main control module 21, it sends test optical pulses to the target fiber optic link currently being switched by the optical switch module 22, and receives optical signals returned from the target fiber optic link, converts them into test data in electrical signal form, and then transmits them back to the main control module 21. The MPO interface 24 is connected to the optical switch module 22 and is configured to interface with an external multi-core MPO optical cable via an MPO connector to establish optical path connections between the optical switch module 22 and the individual fiber cores of the multi-core MPO optical cable.

[0028] It should be noted that the multi-fiber link automated testing system 1 of this application embodiment is mainly applicable to scenarios such as data centers, telecommunications backbone networks, metropolitan area networks, and enterprise campus networks for link verification, performance certification, and routine fault diagnosis of multi-core MPO optical cables. In actual use, technicians only need to directly insert the multi-core MPO optical cable to be tested into the MPO interface 24 of the OTDR testing device 20, and then select the test mode and configure the test parameters on the human-machine interface screen 11 of the handheld testing platform 10. The system will then automatically complete the testing of each fiber core sequentially. Throughout the testing process, the channel switching of the optical switch module 22, the optical pulse transmission and signal acquisition of the OTDR optical transceiver module 23, and the return and analysis of test data are all automatically completed by the system, without the need for manual insertion and removal of optical fibers or manual switching of test channels. After the test is completed, the test results of each fiber core will be displayed on the human-machine interface screen 11, and technicians can directly view and judge the link quality of each fiber core on the device.

[0029] Furthermore, the OTDR testing device 20 in this embodiment can be integrated as a pluggable module of the handheld testing platform 10, or it can be used independently as a testing module in conjunction with other devices as needed.

[0030] In this way, the automated multi-fiber link testing system 1 of this application embodiment, through the above-described structural configuration, highly integrates the handheld testing platform 10, the OTDR optical transceiver module 23, and the optical switch module 22, and sets up an MPO interface 24 to directly connect to an external multi-core MPO optical cable. The handheld testing platform 10 controls the optical switch module 22 to automatically switch between the individual fiber cores of the multi-core MPO optical cable, achieving automated core-by-core testing of each fiber core in the multi-core MPO optical cable. Compared to the existing technology that requires manual testing of each fiber core using fan-out branch cables, this automated multi-fiber link testing system 1 can directly connect to the multi-core MPO optical cable without additional branch cables. During the testing process, it can complete the testing and data analysis of the multi-core link without manual intervention, significantly improving the testing efficiency and accuracy of multi-core fiber optic links and reducing maintenance costs.

[0031] In some examples, such as Figure 1 , Figure 2 and Figure 3 As shown, the handheld testing platform 10 is a testing platform developed based on at least one of the Android, iOS, and HarmonyOS systems. Developing based on a mature mobile operating system allows full utilization of its rich software ecosystem, robust graphical interface development framework, and broad hardware compatibility, significantly reducing application software development cycles and costs. Simultaneously, such operating systems possess mature and stable mechanisms for multi-tasking management, process scheduling, and memory management, ensuring the stability and smoothness of test applications under long-term operation and continuous multi-fiber testing scenarios. Furthermore, technicians can quickly learn to operate the device without additional training, lowering the barrier to entry for users.

[0032] It should be noted that the handheld testing platform 10 in this example is preferably developed based on the Android system, due to its open-source nature, wide selection of terminal devices, and controllable cost, which balances performance and cost-effectiveness. In actual implementation, developers can use Android's standard Activity / Fragment to build the human-computer interaction interface and achieve data interaction with the OTDR testing device 20 through the serial communication API or USB Host API provided by the Android SDK. When choosing the iOS system, Swift language and the ExternalAccessory framework in the iOS SDK can be used for development; when choosing the HarmonyOS system, ArkTS language and the relevant communication interfaces 30 in the HarmonyOS SDK can be used for development. Regardless of the operating system used, the software architecture and interaction logic of its core functional modules (parameter configuration, command issuance, data reception, analysis and processing, and result display) remain consistent, with only differences in the underlying system calls and interface driver implementation.

[0033] In some examples, such as Figure 1 , Figure 2 and Figure 3 As shown, the communication interface 30 can be any one of a USB interface, Bluetooth interface, WiFi interface, or Ethernet interface. The handheld test platform 10 and the OTDR test device 20 exchange data through the corresponding communication protocol. This allows for flexible selection of the most suitable communication method based on the actual field environment and equipment configuration, balancing data transmission rate, connection stability, and ease of use. The USB interface provides high-speed, high-reliability wired data transmission, especially suitable for scenarios with large test data volumes and high real-time requirements. The Bluetooth interface has low power consumption and convenient connection, suitable for short-range wireless operation. The WiFi interface has a high transmission rate and wide coverage, suitable for remote monitoring within a local area network. The Ethernet interface is suitable for fixed workstation or rack-mounted deployment scenarios, enabling long-distance, high-stability wired network connections.

[0034] It should be noted that when using a USB interface, the handheld test platform 10 acts as a USB host device, and the OTDR test device 20 acts as a USB device. Communication between the two can be achieved using either the USB HID or USB CDC protocol. The USB CDC protocol virtualizes the OTDR test device 20 as a serial port device, facilitating the upper-layer application's serial port read / write operations for sending and receiving commands and data. When using a Bluetooth interface, either the Bluetooth SPP (Serial Profiler Protocol) or BLE (Bluetooth Low Energy) protocol can be used. SPP is suitable for large data transfers, while BLE is better suited for low-power, intermittent data transmission scenarios. When using a WiFi interface, the handheld test platform 10 and the OTDR test device 20 can establish a socket connection via TCP / IP or use an HTTP / RESTful API for command issuance and data transmission. When using an Ethernet interface, data interaction is also based on the TCP / IP protocol stack, and PoE (Power over Ethernet) technology can be used to simultaneously achieve power supply and communication. When implementing various communication methods, the corresponding protocol stack and data processing logic must be implemented in the application layer of the handheld test platform 10 and the firmware layer of the OTDR test device 20 respectively to ensure the correct encapsulation, transmission, reception and parsing of instructions and data.

[0035] In some examples, such as Figure 1 and Figure 2 As shown, the optical switch module 22 is a 1×N optical switch, where N is a positive integer greater than or equal to 2. The common terminal of the optical switch module 22 is connected to the OTDR optical transceiver module 23. The N output terminals of the optical switch module 22 are respectively connected to the N optical fiber links in the MPO interface 24. The N optical fiber links in the MPO interface 24 are also connected to the N fiber cores of the multi-core MPO optical cable through the MPO connector. Under the control of the main control module 21, the optical path between the OTDR optical transceiver module 23 and each fiber core in the multi-core MPO optical cable is switched one by one to realize the one-by-one testing of each fiber core in the multi-core MPO optical cable. In this way, the optical signal of one OTDR optical transceiver module 23 can be switched to N different fiber cores in a time-division manner through a single 1×N optical switch, realizing the time-division multiplexing of a single OTDR core optoelectronic device between multiple fiber links. There is no need to configure an independent OTDR optical transceiver module 23 for each fiber core, which significantly reduces the hardware cost, size and power consumption of the system, and also simplifies the workload of optical path calibration and consistency maintenance.

[0036] It should be noted that the optical switch module 22 in this example can specifically be a MEMS optical switch or a mechanical optical switch. MEMS optical switches change the optical path through electrostatic or electromagnetic actuation of miniature mirrors, offering advantages such as small size, fast switching speed (typically in the millisecond range), long lifespan, and good repeatability, making them suitable for automated testing scenarios with frequent switching. Mechanical optical switches achieve optical path switching by driving prisms or fiber collimators with stepper motors or relays. They have low insertion loss (controllable below 0.5dB) and low inter-channel crosstalk, but their switching speed is relatively slow (typically in the tens to hundreds of milliseconds range) and their size is larger. In practical selection, the choice can be made based on the comprehensive requirements of switching speed, insertion loss, size, and cost. Regardless of the type of optical switch used, its common terminal must be connected to the OTDR optical transceiver module 23, and each output terminal must be connected to each fiber optic link within the MPO interface 24 via fiber optic patch cords or optical waveguides to ensure that the optical path coupling efficiency meets the dynamic range requirements of OTDR testing.

[0037] In some examples, such as Figure 1 and Figure 4 As shown, the optical switch module 22 includes 1×12-channel, 1×16-channel, and 1×24-channel optical switches to adapt to 12-core, 16-core, or 24-core multi-core MPO optical cable testing. This allows for seamless integration with the most widely used 12-core, 16-core, and 24-core MPO connectors in data centers and high-speed interconnects, covering the needs of most practical application scenarios. The 1×12-channel optical switch corresponds one-to-one with a 12-core MPO optical cable, the 1×16-channel optical switch corresponds one-to-one with a 16-core MPO optical cable, and the 1×24-channel optical switch corresponds one-to-one with a 24-core MPO optical cable. The optical path switching logic is clear, requiring no additional channel mapping or adaptation conversion.

[0038] It should be noted that the aforementioned 12-pin MPO connector uses a single-row 12-pin arrangement and is typically used in parallel optical transmission applications such as 40G / 100G SR4 (with 4 pins for transmitting, 4 pins for receiving, and 4 pins idle or spare), as well as multi-path parallel transmission scenarios in 10G / 25G Ethernet. The aforementioned 16-pin MPO connector uses a single-row 16-pin arrangement and is typically used in parallel optical transmission applications such as 400G SR8 (with 8 pins for transmitting and 8 pins for receiving), and other high-density parallel interconnect scenarios. Its fiber count is between 12 and 24 pins, and it has wide application requirements in some high-speed interconnect solutions. The aforementioned 24-pin MPO connector uses a dual-row 12-pin arrangement (12 pins per row) and is commonly used in higher-speed parallel optical interconnect scenarios such as 200G / 400G / 800G. It has a higher fiber density and requires a higher degree of automation in testing. In actual implementation, the output of the 1×12 optical switch is connected one-to-one with the 12 optical fiber links in the MPO interface 24, the output of the 1×16 optical switch is connected one-to-one with the 16 optical fiber links in the MPO interface 24, and the output of the 1×24 optical switch is connected one-to-one with the 24 optical fiber links in the MPO interface 24. The main control module 21 controls the drive circuit of the optical switch to switch the common end to the corresponding output end, thereby connecting the corresponding fiber core for testing.

[0039] In some examples, such as Figure 1 and Figure 4 As shown, the optical switch module 22 is a cascaded multi-channel optical switch to adapt to the testing of multi-core MPO optical cables with more than 24 cores. In this way, by cascading multiple optical switches, the number of channels can be flexibly expanded based on a single standard optical switch product to meet the testing needs of high-density MPO optical cables with 32, 48, 72, or even more fiber cores, thereby improving the scalability and adaptability of the system.

[0040] It should be noted that the cascading method in this example can specifically adopt a two-stage or multi-stage serial structure. Taking the expansion of 48 channels as an example, a cascading scheme can be adopted with a first stage of 1×4 optical switches and a second stage of four 1×12 optical switches. The common terminal of the first-stage optical switch is connected to the OTDR optical transceiver module 23, and the four output terminals of the first-stage optical switch are respectively connected to the common terminal of the four 1×12 optical switches. The twelve output terminals of each 1×12 optical switch are respectively connected to the twelve fiber optic links in the MPO interface 24, thus forming a 1×48-channel optical switch. The main control module 21 needs to control the switching state of the first-stage and second-stage optical switches simultaneously. When it is necessary to switch to the i-th channel (i=1~48), the first-stage channel number and the second-stage channel number corresponding to i are first calculated, and then the corresponding optical switches are driven in sequence to complete the switching. Each optical switch in the cascaded structure can be a MEMS optical switch or a mechanical optical switch. The total insertion loss after cascading is the sum of the insertion losses of each optical switch. When designing the system, it is necessary to ensure that the total insertion loss is still within the dynamic range acceptable for OTDR testing.

[0041] In some examples, such as Figure 1 and Figure 4 As shown, the OTDR testing device 20 also includes a wavelength selection module 25, which is connected to both the main control module 21 and the OTDR optical transceiver module 23. Under the control of the main control module 21, the wavelength selection module 25 selects a target wavelength from a variety of preset test wavelengths, causing the OTDR optical transceiver module 23 to emit test light pulses corresponding to the target wavelength. The preset test wavelengths are either single-mode or multi-mode combinations. Thus, this multi-channel fiber optic link automated testing system can simultaneously support both single-mode and multi-mode MPO optical cable testing scenarios. Users can flexibly switch wavelength combinations in the test parameter configuration interface according to the actual type of optical cable under test. By switching test wavelengths under the unified control of the main control module 21, automated switching between different wavelength tests can be achieved without replacing the laser 231 or other hardware modules. Users can flexibly select the optimal wavelength according to the actual test scenario (such as different fiber types or different transmission distances), expanding the system's application range and testing flexibility.

[0042] It should be noted that in this example, the wavelength selection module 25 can be positioned after the laser 231 and before the optical switch module 22 of the OTDR optical transceiver module 23. That is, the broadband or tunable light emitted from the laser 231 first passes through the wavelength selection module 25 to filter out the target wavelength before entering the optical switch module 22 and being switched to the target fiber core. The switching between different wavelengths by the wavelength selection module 25 is driven by the main control module 21 through digital control signals (such as I2C bus, SPI bus, or GPIO control signals). After the switching is completed, the main control module 21 notifies the OTDR optical transceiver module 23 to start optical pulse transmission and data acquisition. The wavelength selection process is usually completed before testing each fiber core. When different fiber cores require different wavelengths, the main control module 21 can adjust the state of the wavelength selection module 25 during each channel switch.

[0043] In some examples, the single-mode test wavelength combinations mentioned above include 1310nm and 1550nm wavelengths, while the multimode test wavelength combinations include 850nm and 1300nm wavelengths. Thus, this example can automatically match the corresponding wavelength combination based on the type of MPO optical cable under test, ensuring optimal test results under different fiber media. Specifically, the 1310nm wavelength is near the zero-dispersion wavelength of single-mode fiber, with low pulse dispersion, suitable for precise event location and link analysis in short-to-medium distance scenarios; the 1550nm wavelength is within the lowest loss window of single-mode fiber, with a transmission loss of only about 0.2dB / km, suitable for link testing in long-distance backbone networks and metropolitan area networks. For multimode fiber, the 850nm wavelength is the most commonly used operating wavelength for short-distance high-speed data communication. Combined with the higher numerical aperture of multimode fiber, it can obtain good backscattered signal strength, suitable for link testing of tens to hundreds of meters in data centers and campus networks; the 1300nm wavelength has low transmission loss and dispersion in multimode fiber, suitable for multimode link testing at the kilometer level. By integrating the above four wavelengths into the same testing system, users do not need to purchase different OTDR devices for single-mode and multi-mode testing. One device can handle multiple testing scenarios, effectively reducing equipment procurement costs and operation and maintenance complexity.

[0044] It should be noted that the 1310nm and 1550nm wavelengths in the single-mode test wavelength combination in this example are primarily based on the transmission characteristics of ITU-T G.657.A2 standard single-mode fiber. This type of fiber exhibits the same low transmission loss and good backscattering characteristics as G.652.D fiber at wavelengths of 1310nm and 1550nm. Furthermore, these two wavelengths are recognized as standard test wavelengths in the OTDR testing field and are widely used in the testing of various single-mode fibers (including G.657.A2 and G.652.D), demonstrating good versatility and comparability. The 850nm and 1300nm wavelengths in the multimode test wavelength combination in this example are based on the transmission characteristics of ITU-T G.651 standard multimode fiber. 850nm corresponds to the first transmission window of the multimode fiber, and 1300nm corresponds to the second transmission window; both are the most commonly used test wavelengths in multimode fiber communication. In practical implementation, the wavelength selection module 25 can automatically switch to the corresponding wavelength combination according to the test mode (single-mode test mode or multi-mode test mode) selected by the user on the test parameter configuration interface of the handheld test platform 10. Alternatively, the user can manually select the required single or multiple wavelengths from the list of available wavelengths. When the user selects the single-mode test mode, the wavelength field value carried in the test parameter configuration command issued by the handheld test platform 10 is set to 1310nm or 1550nm, and the main control module 21 controls the wavelength selection module 25 to filter out the test light pulse of the corresponding wavelength from the light signal output by the laser 231. When the user selects the multi-mode test mode, it switches to 850nm or 1300nm accordingly. Furthermore, the test parameter configuration interface of the handheld test platform 10 can dynamically adjust the recommended value range of other related parameters according to the currently selected test mode. For example, in single-mode test mode, the pulse width and test range range are larger to adapt to longer test distances, while in multi-mode test mode, they are correspondingly smaller to adapt to short-distance, high-precision test requirements, thus providing users with a more intelligent and user-friendly parameter configuration experience. In terms of hardware implementation, the laser 231 can be a multi-wavelength laser component capable of generating multiple wavelengths, integrating multiple laser diode chips of different wavelengths. The corresponding wavelength chip can be made to emit light by selecting the appropriate drive circuit through the main control module 21. Alternatively, the laser 231 can be a single tunable laser, achieving different wavelength outputs by changing the laser's drive current or operating temperature.The interaction between the wavelength selection module 25 and the laser 231 can be flexibly determined according to the specific hardware architecture: when the laser 231 is a multi-wavelength laser component, the wavelength selection module 25 mainly plays the role of wavelength selection and purity optimization, ensuring that wavelength components other than the target wavelength in the output light are sufficiently suppressed; when the laser 231 is a single-wavelength laser and needs to support multi-wavelength testing, different laser modules or multiple single-wavelength lasers need to be replaced or configured and selected by an optical switch. In this case, the wavelength selection module 25 can work with the corresponding laser gating mechanism to complete the wavelength switching. Regardless of the hardware implementation method used, the wavelength of the test light pulse finally output to the optical switch module 22 is consistent with the target wavelength configured by the user, ensuring the accuracy and consistency of the test.

[0045] In some examples, such as Figure 1 and Figure 4 As shown, the wavelength selection module 25 can specifically be a tunable filter or a wavelength splitter. This allows for flexible selection of the implementation method based on different performance requirements and cost budgets. When using a tunable filter, the wavelength can be quickly and continuously tuned to the target wavelength via electronic control, offering high flexibility and eliminating the need for additional optical switches. When using a wavelength splitter, the input light can be separated into different output ports according to wavelength, and then an optical switch can be used to select the desired wavelength output port. This method is simple in structure and low in cost, but requires an additional wavelength channel selection switch.

[0046] It should be noted that the tunable filter in this example can be a Fabry-Perot tunable filter, which adjusts the transmitted wavelength by changing the driving voltage of the filter cavity, offering fast tuning speed and high wavelength resolution. An acousto-optic tunable filter can also be used, which selects the transmitted wavelength by changing the frequency of the radio frequency signal applied to the acousto-optic crystal. The wavelength splitter in this example can be an arrayed waveguide grating or a dielectric film filter type wavelength division multiplexer 233, which separates optical signals of different wavelengths to different physical ports, and then selects the target wavelength output through an additional 1×M optical switch (M being the number of supported wavelengths). In practical implementation, the tunable filter solution is smaller in overall size and simpler to control, making it suitable for portable devices. The wavelength splitter plus optical switch solution offers better insertion loss and consistency across wavelength channels, making it suitable for applications requiring higher testing accuracy.

[0047] In some examples, such as Figure 1 and Figure 4As shown, the OTDR optical transceiver module 23 may specifically include a laser 231, a photodetector 232, a wavelength division multiplexer 233, and a signal processing unit 234. The laser 231 is configured to generate test optical pulses under the control of the main control module 21. The wavelength division multiplexer 233 is configured to couple the test optical pulses to the current channel of the optical switch module 22 and separate the optical signal returned from the target fiber optic link to the photodetector 232. The photodetector 232 is configured to convert the received optical signal into an analog electrical signal. The signal processing unit 234 is configured to amplify, filter, and perform analog-to-digital conversion on the analog electrical signal to generate digitized test data. Thus, bidirectional optical signal transmission—sending test optical pulses outward and receiving backscattered and reflected light inward—is achieved through the wavelength division multiplexer 233 at the same fiber optic port. This allows the OTDR optical transceiver module 23 to complete the transmission and reception functions with only a single optical port, simplifying the optical path structure and fiber optic connection. Under the control of the main control module 21, the laser 231 can precisely adjust the width and peak power of the optical pulse to adapt to fiber optic links of different lengths and loss characteristics. The amplification and filtering circuits in the signal processing unit 234 can effectively extract weak signals and suppress noise, while the analog-to-digital converter digitizes the analog signal at a high sampling rate, providing a high-quality data foundation for subsequent event detection and link analysis.

[0048] It should be noted that the laser 231 in this example can specifically be a pulsed semiconductor laser diode, which emits light pulses of corresponding width and amplitude under the drive of the pulsed current provided by the main control module 21. The center wavelength of the laser 231 is determined by the wavelength selection module 25, or by the material structure of the laser 231 itself (in the absence of the wavelength selection module 25). The wavelength division multiplexer 233 in this example can be a thin-film filter type wavelength division multiplexer 233 or a fiber Bragg grating type wavelength division multiplexer 233, which separates the output light and input light of the OTDR optical transceiver module 23 in terms of wavelength—usually the output light (test light pulse) and the input light (backscattered light) use the same wavelength, in which case the wavelength division multiplexer 233 actually acts as an optical circulator; wavelength separation can also be achieved when the output light and input light use different wavelengths. The photodetector 232 in this example can be an avalanche photodiode, whose internal gain mechanism can significantly improve the detection sensitivity to weak backscattered light, and in conjunction with a transimpedance amplifier, convert the photocurrent into a voltage signal. The signal processing unit 234 in this example includes a preamplifier, a main amplifier, a low-pass filter, and an analog-to-digital converter. The sampling rate of the analog-to-digital converter determines the distance resolution of the OTDR, which is typically no less than 100 MSPS (millions of samples per second) and the quantization bit depth is no less than 12 bits to ensure accurate acquisition of changes in weak light signals.

[0049] In some examples, such as Figure 1 and Figure 5As shown, the handheld testing platform 10 also includes a parameter configuration module 111, a command issuance module 112, a data receiving module 113, a data processing module 114, and a result display module 115. The parameter configuration module 111 provides a graphical interface for configuring test parameters via a human-machine interface screen 11, receiving and verifying the rationality of user-configured test parameters. The command issuance module 112 generates control commands conforming to the communication protocol format based on the test parameters and issues them to the OTDR testing device 20 via the communication interface 30. The data receiving module 113 receives test data returned by the OTDR testing device 20 via the communication interface 30 and parses and verifies the test data. The data processing module 114 performs event detection and link analysis on the parsed and verified test data and generates test results including at least fiber length, connector loss, reflection events, and link attenuation. The result display module 115 visualizes the test results on the human-machine interface screen 11 in a preset display format. Thus, by integrating the complete testing process software functionality into the handheld testing platform 10, a fully automated closed-loop process is achieved, encompassing parameter configuration, command control, data reception, analysis and processing, and result display. Users can start testing with simple configuration through the graphical interface, without requiring professional OTDR command knowledge or programming skills, significantly lowering the operational threshold. The clear division of responsibilities and smooth data flow between software modules ensures excellent maintainability and scalability of the software architecture, facilitating subsequent functional iterations and upgrades.

[0050] It should be noted that the aforementioned software modules are specifically implemented by test applications running on the operating system of the handheld test platform 10. When verifying the rationality of the user configuration, the parameter configuration module 111 can check the matching between the pulse width and the test range (for example, when the range is small, an excessively wide pulse will cause a blind zone covering the entire test range), and whether the test duration is within a reasonable range (usually 10 to 180 seconds). If an unreasonable configuration is found, a prompt will be given and corrections will be suggested. When generating control commands, the command issuance module 112 must encapsulate the commands according to the communication protocol agreed upon between the handheld test platform 10 and the OTDR test device 20. For example, parameters such as channel number, wavelength value, pulse width value, range value, and average time are filled into specified fields according to the protocol frame format, and a frame header, frame tail, and check fields (such as CRC check or checksum) are added to ensure the correctness of command transmission. After receiving the returned test data, the data receiving module 113 first performs frame verification to eliminate transmission errors, and then parses the OTDR curve data points (each data point corresponds to an optical power value at a distance position) and related test status information according to the protocol format. When performing event detection, the data processing module 114 can use a threshold method based on slope change detection to search for locations where the slope abruptly changes on the OTDR backscattering curve, and combine this with the amplitude of the reflection peak to determine the event type (such as joints, fusion points, break points, connectors, etc.), thereby calculating the location, loss value, and reflection coefficient of each event point. When visualizing the results, the result display module 115 can use a cross-platform graphics rendering engine (such as Canvas or OpenGL on the Android platform) to draw OTDR curve graphs, event list tables, and link overview graphs on the screen, and support interactive functions such as zooming, panning, and marking based on user operations.

[0051] In some examples, the aforementioned test parameters include at least one of the following: fiber core channel selection parameters, test wavelength selection parameters, pulse width parameters, test range parameters, and test duration parameters. This allows users to flexibly configure these parameters according to actual test needs and the specific conditions of the fiber optic link under test, achieving optimal test quality and efficiency. Different parameter combinations directly affect the OTDR's dynamic range, dead zone size, distance resolution, and test time, allowing users to fine-tune the settings based on experience or standard test procedures, thus improving the system's adaptability to diverse test scenarios.

[0052] It should be noted that the specific meanings and value ranges of each test parameter in this example are as follows: The fiber core channel selection parameter specifies the list of fiber core numbers to be measured in this test. Users can select all channels or only select specific channels; the test wavelength selection parameter specifies the wavelength used in this test, and one or more options can be selected from 850nm, 1300nm, 1310nm, 1550nm, etc. The pulse width parameter determines the duration of the light pulse emitted by the laser 231. The selectable range is 3ns, 5ns, 10ns, 30ns, 50ns, 100ns, 275ns, 500ns, 1μs, 2.5μs, 10μs, 20μs, etc. A larger pulse width results in higher light energy injected into the fiber and a larger dynamic range, but the dead zone also increases accordingly, making it suitable for long-distance testing; a smaller pulse width results in a smaller dead zone and higher distance resolution, making it suitable for short-distance high-precision testing. The test range parameter is used to set the sampling distance range of the OTDR. Selectable ranges include 0.1km, 0.65km, 1.25km, 2.5km, 5km, 10km, 20km, 40km, 80km, 120km, 160km, and 260km. The range should be set slightly larger than the total length of the fiber being tested to ensure complete backscattering curve acquisition. The test duration parameter is the average sampling time for each test. Selectable ranges include 5s, 10s, 15s, 30s, 45s, 60s, 90s, 120s, and 180s. A longer test duration results in better suppression of random noise through averaging and a higher signal-to-noise ratio, but also increases test time. Specific values ​​for each parameter can be selected by the user via drop-down menus or sliders in the test parameter configuration interface. After selection, the parameter configuration module 111 performs a validity check.

[0053] In some examples, the aforementioned preset display formats include at least one of graphs, event lists, and link overview diagrams. This allows for the presentation of test results in multiple formats to meet the viewing preferences of technicians with different usage habits and analytical needs. Graphs can display the complete OTDR backscatter trajectory, facilitating technicians' observation of the loss distribution and event characteristics of the entire fiber optic link. Event lists accurately summarize the location, loss, and other parameters of each event point in a structured table format, facilitating rapid location and recording of abnormal events. Link overview diagrams graphically and intuitively display the topology of the fiber optic link and the quality status of each key node, enabling rapid assessment of the overall link health.

[0054] It should be noted that the graph in this example displays the OTDR backscattering trajectory, with the horizontal axis representing distance (in meters or kilometers) and the vertical axis representing optical power (expressed in logarithmic dB). The slope changes at each point on the curve reflect changes in the fiber attenuation coefficient; sudden drops correspond to losses at connectors or fusion splices, and reflection peaks correspond to reflection events such as those at connectors, mechanical joints, or fiber ends. The graph supports multi-touch gestures; users can zoom by pinching with two fingers and pan by dragging with one finger to view local details or the overall picture of the curve. The event list in this example displays each event point in a table format, row by row, along with its sequence number, location (distance), event type (e.g., reflection event, non-reflection event, fiber end, etc.), loss value, reflection coefficient, and cumulative loss. It can also be sorted by loss value or location. The link overview diagram in this example displays a graphical thumbnail view of the fiber optic link, using different colors or symbols to indicate the pass / fail status of each fiber segment, the loss level of each connection point, and arrows or lines to indicate the signal transmission direction. This allows technicians to quickly grasp the overall quality status of the entire link. Users can freely switch between different display formats by clicking tabs or buttons on the interface, and can also display multiple formats simultaneously in different areas of the same interface (e.g., displaying a graph at the top and an event list at the bottom).

[0055] In some examples, such as Figure 1 and Figure 5 As shown, the handheld testing platform 10 also includes a channel status monitoring module 116. The channel status monitoring module 116 is configured to acquire the current fiber core channel number being tested in real time during channel switching by the optical switch module 22, and display the current testing progress on the human-machine interface screen 11. This allows technicians to know at any time during testing which fiber core is being tested, how many fiber cores have been completed, and how many remain to be tested. This facilitates timely pause and problem localization in case of abnormalities (such as significantly abnormal test data for a certain fiber core), and also helps to grasp the overall testing time required, improving the efficiency and management level of on-site testing.

[0056] It should be noted that the channel status monitoring module 116 in this example can obtain the current fiber core channel number in the following ways: after each optical switch switching is completed, the main control module 21 returns a status confirmation frame containing the current channel number to the handheld testing platform 10, and the handheld testing platform 10 updates the interface display upon receiving it; or, when the command issuing module 112 issues a channel switching command each time, the channel status monitoring module 116 records the target channel number in the current command, and after waiting for a certain period of time, confirms that the optical switch has actually switched to the correct position by querying the command. The current test progress can be displayed by simultaneously displaying a progress bar and text prompts in the status bar or a dedicated area on the human-machine interface screen 11. For example, the progress bar can intuitively show the overall completion percentage in percentage form, and the text prompt can specifically display "Testing the 3rd core (out of 12 cores)", and the progress information can be automatically refreshed after each fiber core test is completed.

[0057] In some examples, such as Figure 1 and Figure 5 As shown, the handheld test platform 10 also includes a storage module 117, which is configured to store test parameters, test data, and test results. This allows complete test data to be stored locally on the device, facilitating subsequent review and inspection, historical data comparison and analysis, and the generation and printing of test reports, without worrying about data loss due to power outages or application shutdowns. For scenarios requiring long-term monitoring and periodic testing, the storage and traceability of historical data are particularly crucial, helping maintenance personnel detect slow degradation trends in fiber optic link performance and provide early warnings of potential faults.

[0058] It should be noted that the storage module 117 in this example can be an onboard flash memory chip (such as eMMC or UFS storage chip) built into the handheld testing platform 10, with a capacity typically ranging from 32GB to 256GB, capable of storing a large number of OTDR test curve files; it can also support MicroSD card expansion, allowing users to replace the memory card with a larger capacity one as needed to expand storage space. The stored test data can be in industry-standard OTDR curve file formats such as Bellcore GR-196 or SR-4731 (usually with the .sor extension), a format widely supported by mainstream OTDR data analysis software, facilitating the transfer of test data to a PC for more in-depth professional analysis or archiving management. When saving data, the storage module 117 can create folder structures based on test date, fiber optic cable number, fiber core number, etc., facilitating subsequent retrieval and location. Furthermore, the storage module 117 can also support exporting test results as PDF or CSV report files, convenient for direct printing or sharing.

[0059] In some examples, such as Figure 1 and Figure 5As shown, the handheld test platform 10 also includes a wireless communication module 118. The handheld test platform 10 connects to external devices via the wireless communication module 118 to achieve remote control and data upload. In this way, technicians can remotely view test progress, receive test completion notifications, and even remotely start or stop test tasks from a monitoring center or office far from the test site via terminal devices such as computers, tablets, or mobile phones, greatly improving the flexibility and management efficiency of on-site testing. Simultaneously, test data can be uploaded to a cloud server or enterprise back-end management system in real time, enabling centralized management, unified analysis, and cross-regional sharing of data from multiple test devices, providing data support for the operation and maintenance management of large-scale fiber optic networks.

[0060] It should be noted that the wireless communication module 118 in this example supports both cellular networks (such as 4G LTE or 5G NR) and WiFi wireless LAN. Cellular networks are suitable for outdoor or remote locations without Wi-Fi coverage, while Wi-Fi is suitable for indoor data centers or server rooms with LAN coverage. The wireless communication module 118 establishes a connection with the remote server or terminal device via TCP / IP protocol. Data transmission can use the MQTT (Message Queuing Telemetry Transport) protocol for lightweight data publishing and subscription, or the HTTPS protocol for secure RESTful API data upload. For remote control, the remote terminal can send control commands to the handheld test platform 10 via a web page or a dedicated APP. After receiving the remote command, the handheld test platform 10 starts the test according to the procedure and continuously transmits real-time progress and test data during the test. To ensure communication security, the wireless communication module 118 supports WPA2-PSK (Wi-Fi Secure Access) and TLS (Transport Layer Security) encryption to prevent test data from being stolen or tampered with during transmission.

[0061] In some examples, the aforementioned control commands may specifically include channel switching commands, test start commands, and test parameter configuration commands. The main control module 21 controls the optical switch module 22 to switch to the target channel according to the preset channel switching logic based on the channel switching command. The main control module 21 controls the OTDR optical transceiver module 23 to emit test optical pulses according to the test start command. The main control module 21 configures the test parameters of the OTDR optical transceiver module 23 according to the test parameter configuration command. Thus, the control function is decomposed into three categories of independent commands with clear responsibilities and well-defined formats, facilitating the standardized design of the communication protocol between the handheld test platform 10 and the OTDR test device 20 and the modular implementation of the underlying firmware. The decomposition of commands allows each function to be independently invoked and executed in combination. For example, a channel switching command can be issued separately during testing to adjust the test order, or a test parameter configuration command can be issued separately to dynamically adjust the test parameters of the current fiber core, improving the flexibility of control and the ability to handle abnormal situations.

[0062] It should be noted that in the actual testing process, the three commands are usually used in combination in the order of "parameter configuration - channel switching - test start": First, the handheld test platform 10 issues a test parameter configuration command, writing parameters such as wavelength, pulse width, range, and averaging time into the register of the main control module 21 of the OTDR test device 20; then, a channel switching command is issued, and the main control module 21 drives the optical switch module 22 to switch to the target fiber core channel, and informs the handheld test platform 10 that the switch is in place through a status confirmation frame after the switch is completed; finally, a test start command is issued, and the main control module 21 controls the OTDR optical transceiver module 23 to start transmitting test light pulses and collecting backscatter data. After the data is collected, the test data is packaged and sent back to the handheld test platform 10. To improve communication efficiency, the three commands can also be combined into a single composite command and issued at once. The main control module 21 of the OTDR test device 20 then parses the command and executes the corresponding operations sequentially. If an abnormality occurs during the test (such as a test timeout for a certain channel), the handheld test platform 10 can issue a channel switching command to skip the current channel, or reissue a test start command to retry.

[0063] In some examples, the channel switching logic mentioned above includes at least one of sequential scanning, custom channel, and breakpoint resume testing. Sequential scanning switches the channels corresponding to the optical switch module 22 one by one in ascending order of fiber core number. Custom channel switching switches only to the channel corresponding to one or more target fiber cores selected by the user in the test parameter configuration interface. Breakpoint resume testing records the channel corresponding to the currently tested fiber core during the test and resumes the test from the next untested fiber core's channel when restarted after an interruption. This allows for flexible selection of the most suitable channel switching logic based on different test requirements and site conditions. Sequential scanning is suitable for initial comprehensive testing or routine inspections, completing the test of all fiber cores at once and ensuring no fiber core is missed. Custom channel switching is suitable for scenarios where a specific fiber core is known to be faulty and requires retesting, or where only a few fiber cores need sampling inspection, significantly saving unnecessary testing time. The breakpoint resume testing method is suitable for scenarios where the test is interrupted due to battery depletion, unexpected power failure of the equipment, or user-initiated pause. It avoids repetitive work and time waste caused by starting the test from scratch, and is especially suitable for testing multi-core MPO optical cables with a large number of fiber cores.

[0064] It should be noted that in sequential scanning mode, the main control module 21 automatically increments the channel number by 1 after each test and reports test completion to the handheld testing platform 10 after reaching the maximum channel number. In custom channel mode, the target channel number carried in the channel switching command issued by the handheld testing platform 10 comes from the fiber core list selected by the user in the test parameter configuration interface. The main control module 21 switches sequentially according to the list order, and ends after testing the last channel in the list. In breakpoint resume testing mode, a test status record file is persistently saved in the storage module 117 of the handheld testing platform 10. This file contains a list of fiber core numbers that have been tested, the path of the test data file corresponding to each fiber core, and the current progress percentage. When the user restarts the test due to an interruption and selects "continue testing", the handheld testing platform 10 reads the status file and, starting from the first fiber core number that has not yet been completed, sequentially issues channel switching commands and test start commands to continue testing the remaining fiber cores. After all tests are completed, the status record file can be automatically cleared or marked as "completed" to avoid repeated testing due to accidental operation.

[0065] In some examples, such as Figure 1 , Figure 2 and Figure 3 As shown, the OTDR testing device 20 is a pluggable module with an independent housing. The handheld testing platform 10 is provided with a mounting slot 12 that matches the shape of the OTDR testing device 20, and the communication interface 30 is exposed in the mounting slot 12 and on the outer surface of the OTDR testing device 20. The OTDR testing device 20 is detachably installed in the mounting slot 12 and physically and electrically connected to the handheld testing platform 10 through the communication interface 30. In this way, the OTDR testing device 20, as an independent module, can be flexibly plugged in and replaced. When it is necessary to adapt to MPO optical cables with different core counts (such as 12 cores, 24 cores or higher) or different test wavelength configurations, only the corresponding OTDR testing module needs to be replaced without replacing the entire device. The main body of the handheld testing platform 10 can continue to be used, effectively reducing the upgrade cost and maintenance expenses of the equipment. The modular design also facilitates the return of the equipment for repair—when the OTDR testing device 20 experiences a hardware failure, the module can be disassembled and sent for repair separately or a spare module can be directly replaced without affecting the normal use of the main body of the handheld testing platform 10.

[0066] It should be noted that the mounting slot 12 in this example can be equipped with guide rails and positioning clips to ensure that the OTDR test device 20 is accurately positioned and reliably connected after being inserted in the correct direction, avoiding poor contact of the communication interface 30 or misalignment of the optical path due to installation deviation. The communication interface 30 is located at the bottom or side wall of the mounting slot 12. When the OTDR test device 20 is fully inserted into the slot, its interface automatically mates with the interface in the slot, enabling simultaneous connection of the data cable and power cable. The communication interface 30 can adopt a board-to-board connector (such as a BTB connector) or a USB socket-plug mating structure. The board-to-board connector features low height, reliable contact, and suitability for repeated insertion and removal. The mounting slot 12 can also be equipped with a spring-loaded ejection mechanism or a push-rod ejection mechanism to facilitate easy removal of the OTDR test device 20 when replacing modules. In addition, the mounting slot 12 can be equipped with an anti-misinsertion structure (such as an asymmetrical guide groove or positioning pin) to prevent users from inserting incompatible modules into the slot, causing electrical damage or communication abnormalities. The handheld test platform 10 can power the OTDR test device 20 through the communication interface 30 in the mounting slot 12. The OTDR test device 20 does not require a separate battery or external power adapter, which further simplifies the device connection during field use.

[0067] In summary, the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. An automated testing system for multi-channel fiber optic links, characterized in that, The automated testing system for multi-fiber links includes a handheld testing platform and an OTDR testing device, wherein... The handheld testing platform has a human-computer interaction screen, which is set to receive test parameters configured by the user, and connect to the OTDR testing device through a communication interface to send control commands to the OTDR testing device, and receive and process the test data returned by the OTDR testing device to display the corresponding test results. The OTDR testing device includes a main control module, an optical switch module, an OTDR optical transceiver module, and an MPO interface. The main control module is configured to receive and parse control commands through the communication interface to coordinate and control the operation of various functional modules within the OTDR testing device according to the parsed commands, and to transmit the collected test data back to the handheld testing platform through the communication interface. The optical switch module is connected to the main control module and is configured to switch the optical signal to the target optical fiber link under the control of the main control module. The OTDR optical transceiver module is connected to both the main control module and the optical switch module, and is configured to send test optical pulses to the target optical fiber link currently switched by the optical switch module under the control of the main control module, and receive the optical signals returned from the target optical fiber link, convert them into test data in the form of electrical signals, and transmit them back to the main control module. The MPO interface is connected to the optical switch module and is configured to interface with an external multi-core MPO optical cable through an MPO connector to establish an optical path connection between the optical switch module and each fiber core in the multi-core MPO optical cable.

2. The automated testing system for multi-channel fiber optic links according to claim 1, characterized in that, The handheld testing platform is a testing platform developed based on at least one of the Android system, iOS system and HarmonyOS system; And / or, The communication interface is any one of USB, Bluetooth, WiFi, or Ethernet interfaces, and the handheld test platform and the OTDR test device exchange data through the corresponding communication protocol.

3. The automated testing system for multi-channel fiber optic links according to claim 1, characterized in that, The optical switch module is a 1×N-channel optical switch, where N is a positive integer greater than or equal to 2. The common terminal of the optical switch module is connected to the OTDR optical transceiver module. The N output terminals of the optical switch module are respectively connected to the N optical fiber links in the MPO interface. The N optical fiber links in the MPO interface are also connected to the N fiber cores of the multi-core MPO optical cable through MPO connectors. Under the control of the main control module, the optical path between the OTDR optical transceiver module and each fiber core in the multi-core MPO optical cable is switched one by one, so as to realize the one-by-one testing of each fiber core in the multi-core MPO optical cable.

4. The automated testing system for multi-channel fiber optic links according to claim 3, characterized in that, The optical switch module is any one of a 1×12-channel optical switch, a 1×16-channel optical switch, or a 1×24-channel optical switch, to adapt to testing of 12-core, 16-core, or 24-core multi-core MPO optical cables; or, The optical switch module is a cascaded multi-channel optical switch to adapt to testing of multi-core MPO optical cables with more than 24 cores.

5. The automated testing system for multi-channel fiber optic links according to claim 1, characterized in that, The OTDR testing device further includes a wavelength selection module, which is connected to the main control module and the OTDR optical transceiver module respectively. The wavelength selection module is configured to select a target wavelength from a variety of preset test wavelengths under the control of the main control module, so that the OTDR optical transceiver module emits a test light pulse corresponding to the target wavelength. The variety of preset test wavelengths are a combination of single-mode test wavelengths or a combination of multi-mode test wavelengths.

6. The automated testing system for multi-channel fiber optic links according to claim 5, characterized in that, The single-mode test wavelength combination includes a 1310nm wavelength and a 1550nm wavelength, and the multi-mode test wavelength combination includes an 850nm wavelength and a 1300nm wavelength; and / or, The wavelength selection module is a tunable filter or a wavelength splitter.

7. The automated testing system for multi-channel fiber optic links according to claim 1, characterized in that, The OTDR optical transceiver module includes a laser, a photodetector, a wavelength division multiplexer, and a signal processing unit, wherein... The laser is configured to generate the test light pulse under the control of the main control module. The wavelength division multiplexer is configured to couple the test optical pulse to the current channel of the optical switch module and separate the optical signal returned from the target optical fiber link to the photodetector; The photodetector is configured to convert the received optical signal into an analog electrical signal; The signal processing unit is configured to amplify, filter, and perform analog-to-digital conversion on the analog electrical signal to generate the digitized test data.

8. The automated testing system for multi-channel fiber optic links according to claim 1, characterized in that, The handheld testing platform also includes a parameter configuration module, a command issuance module, a data receiving module, a data processing module, and a result display module. The parameter configuration module is configured to provide a graphical test parameter configuration interface through the human-computer interaction screen, and to receive and verify the rationality of the test parameters configured by the user. The instruction issuing module is configured to generate control instructions conforming to the communication protocol format based on the test parameters, and issue them to the OTDR test device through the communication interface. The data receiving module is configured to receive test data returned by the OTDR testing device through the communication interface, and to parse and verify the test data. The data processing module is configured to perform event detection and link analysis on the parsed and verified test data, and generate test results that include at least fiber length, connector loss, reflection events, and link attenuation. The result display module is configured to visualize the test results on the human-computer interaction screen in a preset display format.

9. The automated testing system for multi-channel fiber optic links according to claim 8, characterized in that, The test parameters include at least one of the following: fiber core channel selection parameters, test wavelength selection parameters, pulse width parameters, test range parameters, and test duration parameters; and / or, The preset display format includes at least one of line graphs, event lists, and link overview graphs.

10. The automated testing system for multi-channel fiber optic links according to claim 8, characterized in that; The handheld testing platform also includes a channel status monitoring module, which is configured to obtain the fiber core channel number currently being tested in real time during the channel switching process of the optical switch module, and display the current testing progress on the human-machine interaction screen. And / or, The handheld testing platform further includes a storage module, which is configured to store the test parameters, the test data, and the test results; and / or, The handheld testing platform also includes a wireless communication module, which connects the handheld testing platform to external devices to enable remote control and data uploading.

11. The automated testing system for multi-channel fiber optic links according to claim 1, characterized in that, The control commands include channel switching commands, test start commands, and test parameter configuration commands; The main control module controls the optical switch module to switch to the target channel according to the channel switching command and a preset channel switching logic; The main control module controls the OTDR optical transceiver module to emit the test optical pulse according to the test start command; The main control module configures the test parameters of the OTDR optical transceiver module according to the test parameter configuration instructions.

12. The automated testing system for multi-channel fiber optic links according to claim 11, characterized in that, The channel switching logic includes at least one of the following: sequential scanning mode, custom channel mode, and breakpoint continuation testing mode. The sequential scanning method is set to switch and connect each channel corresponding to the optical switch module one by one in ascending order of fiber core number; The custom channel mode is set to switch to the channel corresponding to one or more target fiber cores selected by the user in the test parameter configuration interface; The breakpoint continuation test method is configured to record the channel corresponding to the currently completed fiber core during the test, and when the test is restarted after an interruption, continue the test from the channel corresponding to the next untested fiber core.

13. The automated testing system for multi-channel fiber optic links according to any one of claims 1 to 12, characterized in that, The OTDR testing device is a pluggable module with an independent housing. The handheld testing platform is provided with a mounting slot that matches the shape of the OTDR testing device, and the communication interface is exposed in the mounting slot and on the outer surface of the OTDR testing device. The OTDR testing device is detachably installed in the mounting slot and is physically and electrically connected to the handheld testing platform through the communication interface.

Images