A method for realizing compatibility and scalability of radio frequency switch matrix driving
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- 10TH RES INST OF CETC
- Filing Date
- 2023-03-27
- Publication Date
- 2026-06-09
AI Technical Summary
Existing RF switch matrix drivers have issues with compatibility, scalability, and ease of use, and lack line loss compensation functionality, resulting in low development efficiency and significant repetitive work.
By adopting component-level interface specifications and configuration files, combined with the driver framework, the compatibility and scalability of the RF switch matrix are achieved. Line loss information is managed through configuration files, components and path objects are dynamically created, application-level interfaces are provided, and test programs are decoupled.
It improves the compatibility and scalability of RF switch matrix drivers, simplifies the adaptation process, increases development efficiency, and enables automatic compensation for line loss.
Smart Images
Figure CN116418418B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of automatic testing technology for radio frequency signals and is applied to the packaging process of radio frequency switch matrices. Specifically, it is a method for achieving driver compatibility and scalability of radio frequency switch matrices. Background Technology
[0002] An RF switch matrix is a specialized test device composed of multiple single-pole double-throw switches, multiplexed switches, matrices (fully switched switch networks), combiners, power dividers, and other components cascaded together to meet the RF path requirements of the test. By switching different RF switches, the RF switch matrix constructs different RF paths, thus satisfying the RF path requirements between the device under test (DUT) and various test instruments or auxiliary DUTs during the test process. Through the programmable interface of the RF switch matrix, the test software can achieve efficient switching of RF paths during the test, thereby greatly improving test efficiency. Therefore, RF switch matrices are widely used in automated testing processes in fields such as communications, navigation, semiconductors, and smart manufacturing.
[0003] Because the internal components and cascading relationships of RF matrix switches are customized according to testing requirements, it is difficult to propose a unified standard for programmable control interfaces. Due to the lack of such a standard, the programmable control interfaces of RF matrix switches are currently defined by each manufacturer. The programmable control interfaces provided by different manufacturers not only differ in their APIs, but more importantly, their control logic and usage methods are completely different. For example, some RF matrix switches construct paths by controlling the behavior of each switch, while others index the paths using input and output port numbers. This difference in programmable control interfaces leads to a serious problem: users developing test software must relearn and debug the programmable control interfaces of various manufacturers, a process that consumes a significant amount of time and effort. Furthermore, and more seriously, once the model of the RF switch matrix is changed, the significant differences in the programmable control interfaces force programmers to expend considerable effort modifying the test software.
[0004] Currently, the common solution in the industry is to encapsulate the programmable interfaces from different manufacturers into a unified external driver for testing software to use. However, existing driver encapsulation methods have various problems in terms of compatibility, scalability, and ease of use, as detailed below:
[0005] 1. Poor Compatibility: When encapsulating the first RF switch matrix driver, it's always designed for a specific model, without abstracting an interface specification independent of the control logic based on the application. Therefore, during development, a less labor-intensive approach is often adopted. This approach frequently reuses existing programmable interfaces, causing the driver to be coupled with the control logic and usage specific to that RF switch matrix. When compatibility with other matrix programmable interfaces is required, it's discovered that their control logic and usage are drastically different, making driver encapsulation difficult and necessitating modification. Furthermore, due to differences in the coverage of underlying device programmable interfaces from different manufacturers, some driver functions may even be unavailable.
[0006] 2. Significant Repetitive Work: The functions of the components within the RF switch matrix are clearly defined and almost identical. The differences in the programmable interface mainly stem from how to organize the control logic of different components to achieve the application-level interface. Currently, the approach is to repackage the application-level interface. Since the programmable interface already introduces differences in control logic at this point, and the purpose of repackaging is to remove these differences, a lot of unnecessary work is done, resulting in severe repetitive construction.
[0007] 3. Poor scalability: Because the driver is designed with API interfaces for test software calls, it often only provides application-level interfaces related to RF path control, while the component-level driver interfaces used to build the RF path are hidden inside the driver. Therefore, when a new RF path needs to be built, or when matrix hardware is added or removed, the driver program must be modified. Test software developers cannot adapt the matrix through the component-level driver interfaces.
[0008] 4. Poor usability and low development efficiency: The expansion of driver functions or the changes in internal matrix components mean that driver adaptation must be done through coding, rather than through parameter configuration or other non-coding methods. This results in poor usability and low development efficiency in actual test software development.
[0009] 5. Lack of integration of line loss: In an RF switch matrix, the different cascaded components, cable lengths, and signal frequencies of each RF path will cause varying degrees of attenuation to the RF signal strength. However, this attenuation is not negligible in some test items, such as transmit power or receive sensitivity tests. Therefore, before testing, it is necessary to use instruments to measure the attenuation (i.e., line loss) of each RF path and its different frequency points and record it in a line loss table. During testing, it is necessary to retrieve the current line loss value from the line loss table according to the path and corresponding frequency point, and add the line loss value to the measured signal strength to compensate for it in order to obtain the final test result.
[0010] Line loss is closely related to RF switch matrices, but line loss management, including data acquisition and line loss value algorithms, is quite complex. Because acquiring line loss data is time-consuming, it's impossible to collect attenuation values for each frequency in the smallest unit; instead, sampling is necessary. When the frequency value to be queried is not at the sampling point, the line loss value needs to be calculated using algorithms. Common algorithms include taking the maximum / minimum / average value of the line loss values of the two nearest frequencies, or calculating based on a linear relationship. When the test signal is a frequency-hopping signal or wideband signal, all frequency-hopping or wideband sampling points need to be calculated together, again using algorithms such as maximum / minimum / average / linear calculation. Furthermore, matrices often use external fixed attenuators. Fixed attenuators are not part of the matrix; therefore, even if the driver supports line loss-related functions, it's impossible to include the external attenuation value.
[0011] For the reasons mentioned above, existing RF switch matrix drivers often do not support functions related to line loss compensation.
[0012] In summary, the industry urgently needs a design architecture and methodology for RF switch matrix drivers that can be compatible with various customized switching relationships and decoupled from test programs, in order to solve the various problems existing in the current driver packaging methods. Summary of the Invention
[0013] The purpose of this invention is to solve all or at least part of the problems mentioned in the background art, and to provide a design method for a universal driver and related packaging that can be applied to RF switch matrices. This method achieves a comprehensive improvement in the compatibility, scalability and ease of use of RF switch matrices by combining component-level and application-level interface specifications with the configuration files and driver framework of the RF switch matrix.
[0014] The present invention employs the following technical solutions to achieve its objective:
[0015] A method for achieving compatibility and scalability in RF switch matrix driving, the method comprising the following:
[0016] (i) Based on the component-level interface specification, the component-level programmable instructions of a specific RF switch matrix are encapsulated to form a component-level driver that conforms to the interface specification.
[0017] (ii) Based on the component composition and cascade relationship of the RF switch matrix, and on the basis of meeting the configuration file format requirements, create RF switch matrix resources and RF channel configurations to form an RF switch matrix configuration file.
[0018] (III) Use the matrix-driven framework to parse the RF switch matrix configuration file, dynamically create component resource objects and RF path objects, and implement application-level interface functions through the RF path objects;
[0019] (iv) The test software calls the RF path object to achieve the decoupling process between the test program and the specific matrix programmable interface.
[0020] Specifically, when forming the RF switch matrix configuration file, the RF switch matrix resources also include an external fixed attenuator, and the RF channel configuration also includes a line loss table association.
[0021] Furthermore, the matrix-driven framework is used to parse the resource composition information in the RF switch matrix configuration file, and based on the resource composition information, all component resource objects included in the RF switch matrix are dynamically created.
[0022] Furthermore, the matrix-driven framework is used to parse the RF channels defined in the RF switch matrix configuration file and generate RF path objects. The RF path objects contain information on all components cascaded to the RF channels, and control the components in the RF channels according to the component-level interface specifications to implement the relevant functions of the application-level interface.
[0023] Furthermore, the matrix driving framework extracts the difference information between different RF switch matrices in the form of data. The difference information includes component category, component composition, component cascading relationship and component control information. When implementing application-level interface functions, the difference information is used as input parameters and processed by the matrix driving framework to achieve consistency in processing logic.
[0024] Furthermore, the processing code of the matrix driver framework is solidified. When adapting to the new model of RF switch matrix, the matrix driver framework encapsulates the component driver according to the component-level interface specification. The encapsulated component-level driver is used by the matrix driver framework in a direct calling manner, without the need to develop application layer drivers.
[0025] Furthermore, when a new RF channel is added to the RF switch matrix or internal components change and the driver needs to be modified, only the extracted difference information data needs to be modified, without modifying the driver itself.
[0026] Furthermore, the RF switch matrix configuration file is saved in the form of a text file. The matrix driving framework will save the difference information between different RF switch matrices in the RF switch matrix configuration file in the form of a text file. When the RF switch matrix adds a new RF channel or changes its internal components, it can be adapted simply by editing the text of the RF switch matrix configuration file, without the need for encoding.
[0027] Furthermore, in the RF switch matrix configuration file, when the test program calls the test function through the RF channel name, the matrix driving framework associates the RF channel name with the line loss information in the line loss table to complete the line loss value query, calculation and compensation operations.
[0028] Specifically, in the RF switch matrix configuration file, the test program creates RF channel objects by RF channel name, implements switch switching in RF channels through RF channel objects, constructs corresponding RF channels, and adjusts the attenuation value of adjustable attenuators in RF channels to change the expected attenuation of the corresponding RF channels.
[0029] In summary, due to the adoption of this technical solution, the beneficial effects of this invention are as follows:
[0030] Compared with the driving and packaging of traditional RF switch matrices in applications, this invention has the following characteristics:
[0031] 1. Compatibility: Component-level interface specifications and configuration files that extract differences ensure the stability of the driver framework; application-level interface specifications, based on application abstraction rather than specific control logic, ensure consistency in driver call interfaces. Both of these factors together ensure compatibility with different matrix control interfaces, avoiding driver modifications required for each new matrix model.
[0032] 2. Scalability: Expansion of RF switch matrix channels or changes in internal connections can be accommodated simply by modifying the corresponding configuration files. When adding a new matrix model, expansion can be achieved through the component layer interface encapsulation API, which is more flexible and significantly reduces workload compared to traditional methods.
[0033] 3. Ease of use: Since the driving framework of the RF switch matrix extracts the differential parts in the form of configuration files, when it is necessary to expand the RF channel, only the configuration file needs to be modified, which lowers the technical threshold. Testers can even complete the creation and expansion of RF channels by themselves. Therefore, compared with the traditional method, the ease of use is significantly improved.
[0034] 4. Development Efficiency: Expanding matrix pathways or changing internal connections only requires modifying the configuration file, significantly improving development efficiency compared to traditional coding methods. When adding a new matrix, only the API needs to be encapsulated according to the component layer interface standard; the API can be called by the driver framework, greatly reducing workload and improving development efficiency.
[0035] 5. Integrated line loss function: The configuration file can be used to associate line loss files and external fixed attenuators, and the driver framework can automatically complete the line loss compensation operation in the background, realizing the integration of line loss function and improving the efficiency of automatic RF signal testing. Attached Figure Description
[0036] Figure 1 This is a schematic diagram of the logical structure of the method of the present invention;
[0037] Figure 2 This is a schematic diagram of the driving framework architecture of the present invention. Detailed Implementation
[0038] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.
[0039] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.
[0040] Please refer to Figure 1 The illustration illustrates a method for achieving compatibility and scalability in RF switch matrix driving, which can be performed in the following order:
[0041] (I) Based on the component-level interface specification, the programmable instructions for the newly added RF switch matrix components are encapsulated to form a component-level driver conforming to the component-level interface specification. The driver framework supports the expansion of component types, with the main component types including: switches (single-pole double-throw switches, multiplexed switches), matrices (fully switched switch networks), and adjustable attenuators. The interface specifications (Python syntax examples) for each component are shown in Tables 1 to 3:
[0042] Table 1 Switch Interface Specifications
[0043]
[0044] Table 2 Matrix Class Interface Specification
[0045]
[0046]
[0047] Table 3 Interface Specifications for Adjustable Attenuators
[0048]
[0049] (ii) Based on the component composition and cascade relationship of the RF switch matrix, and on the basis of meeting the configuration file format requirements, create RF switch matrix resources and RF channel configurations to form an RF switch matrix configuration file. The configuration file is divided into component resource configuration and RF channel configuration. The channel configuration requires calling the component resources created in the component resource configuration for configuration. Please refer to the following content for a configuration file format example.
[0050] A) The component resource allocation is shown in Tables 4 to 7 below.
[0051] Table 4 Switch Configuration
[0052] name ID type Remark Switch1 1 SPDT Single-pole double-throw switch Switch2 2 SP4T Single-pole four-throw switch Switch3 3 SP6T Single-pole six-throw switch Switch4 4 SP8T Single-pole eight-throw switch
[0053] In Table 4, the name: This switch is uniquely mapped as an input parameter of the calling method and must not have the same name;
[0054] ID: This switch is uniquely mapped as an input parameter to the method call, starting from 1 and must not be repeated;
[0055] Type: Switch type classification for easy understanding and configuration operation; the driver framework will not be parsed.
[0056] Note: For ease of understanding and configuration, the driver framework is not parsed.
[0057] Table 5 Matrix Configuration
[0058] name ID Remark DC_MATRIX 1 Low-frequency matrix VOICE_MATRIX 2 audio matrix
[0059] In Table 5, the name: uniquely maps to this matrix as the input parameter of the calling method, and must not have duplicate names;
[0060] ID: This matrix is uniquely mapped to the input parameter of the method call, starting from 1 and must not be repeated;
[0061] Note: For ease of understanding and configuration, the driver framework is not parsed.
[0062] Table 6 Adjustable Attenuation Configuration
[0063] name ID Remark ATT1 1 Adjustable attenuator 1 ATT2 2 Adjustable attenuator 2
[0064] In Table 6, the name is used as an input parameter to uniquely map the adjustable attenuator and must not be duplicated.
[0065] ID: This ID is used as an input parameter to uniquely identify the adjustable attenuator. It starts from 1 for the same type and cannot be repeated.
[0066] Note: For ease of understanding and configuration, the driver framework is not parsed.
[0067] Table 7 Fixed Attenuation Configuration
[0068] name ID Remark FIX_ATT1 1 Fixed attenuator 1 FIX_ATT2 2 Fixed attenuator 2
[0069] In Table 7, the name is used as an input parameter to uniquely map the fixed attenuator and must not be duplicated.
[0070] ID: This is used as an input parameter to uniquely identify the fixed attenuator. It starts from 1 for the same type and cannot be repeated.
[0071] Note: For ease of understanding and configuration, the driver framework is not parsed.
[0072] B) The RF path configuration is shown in Table 8 below.
[0073] The header of the path configuration table contains all component resources and line loss files. Each configuration row constructs the RF path by selecting the required component resources and setting their status. Configuration content is associated with specific component resources via ID numbers.
[0074] Table 8. Channel Configuration Table
[0075]
[0076] In Table 8, the channel name is used as an input parameter to uniquely map the channel and generate an RF channel object with the channel name as the variable name.
[0077] Switch: Configures the toggle state of each switch. Syntax rules: id(name) = switch index (switch name), choice = connected pin (connected port)], multiple switch configurations are separated by ";", optional, cells can be empty;
[0078] Adjustable Attenuator: Configures the attenuation amount for each adjustable attenuator. Syntax: id(name) = attenuation index(name), default = default attenuation value], optional, cell is empty;
[0079] Fixed Attenuators: Configure the attenuation amount for each fixed attenuator. Syntax: id(name) = attenuation index(name), default = default attenuation value], optional, cell can be empty;
[0080] Matrix: Configures the swapping state of a matrix. Syntax rules: id(name) = matrix index (name), row = row number in the matrix, column = column number in the matrix. Multiple swapping relationships are separated by ";". If not used, this configuration is optional, and the cell will be empty.
[0081] Line loss file: The name of the line loss file corresponding to this path. Syntax rule: Directly enter the line loss file name;
[0082] Note: For ease of understanding and configuration, the driver framework is not parsed.
[0083] (III) The driver framework parses the RF switch matrix configuration file, creates component resource objects and RF path objects, and implements application-level interfaces through the RF path objects. First, the driver framework parses the component resource configuration and dynamically creates various component resource objects with configuration names as variable names. These objects are then used as attributes for the driver to call. Next, the driver framework parses the RF path configuration and instantiates RF path objects. Each RF path object contains handles to the component resource objects required for that path, as well as control parameters. The RF path object can control the component objects according to the component-level interface specification. Based on test requirements, the RF path object abstracts a calling interface unrelated to the control logic, i.e., the application-level interface specification. The RF path object implements application-level interface functions by controlling the aforementioned components. In addition, the framework parses the line loss table configuration and creates a line loss object for that path. The line loss object exists as an attribute of the RF path object for it to call. Internally, the RF path object calls the line loss object interface to implement related operations on line loss. For the driver framework architecture, please refer to [link to relevant documentation]. Figure 2 The illustration.
[0084] (iv) The test software decouples the test program from the specific matrix control interface by calling the application-level interface specification. The application-level interface is implemented through the RF path object, and the relevant interface content is shown in Table 9 below.
[0085] Table 9 Application-level Interface Specification Table
[0086]
[0087]
[0088] The following detailed description of the key points of the method process described in this embodiment will highlight the advantages of the method in this embodiment compared to traditional solutions.
[0089] The method in this embodiment improves compatibility: It proposes component-level and application-level API interface specifications, and designs a general and scalable matrix driver framework based on these specifications. The matrix driver framework extracts the differences between different RF switch matrices as data, including component categories, component composition, component cascading relationships, and component control information. When implementing the application-level interface, this difference information is used as input parameters and processed by the matrix driver framework, ensuring consistency in processing logic and the stability of the driver framework. Furthermore, the application-level interface specification, formed by application abstraction rather than specific control logic, ensures consistency in driver call interfaces. Both of these factors together ensure compatibility with different matrix programmable interfaces.
[0090] The method in this embodiment can reduce the adaptation workload of RF switch matrices: Since the matrix driver framework unifies the interface processing logic from the component level to the application level, the processing code of the matrix driver framework can be solidified. When adapting to a new model matrix, there is no need to rewrite the code. It is only necessary to encapsulate the component-level programmable interface according to the component-level interface specification. The encapsulated component-level driver can be directly called by the matrix driver framework without the need to develop application-level drivers. Therefore, the repetitive work of reorganizing the component control logic is avoided. Since the function of the components is clear and the difference of their programmable interfaces is very small, the adaptation workload is almost negligible.
[0091] The method in this embodiment improves scalability: since the difference information of different RF switch matrices is extracted in the form of data, when a new RF channel is added to the RF switch matrix or the internal components change and the component-level driver needs to be modified, only the extracted difference information data needs to be modified. The data modification process does not require coding, so this method greatly improves the scalability of the matrix driving framework.
[0092] The method in this embodiment improves usability and development efficiency: the matrix driving framework saves the difference information between different RF switch matrices in the form of a text file to the RF switch matrix configuration file. When the RF switch matrix adds a new RF channel, changes internal components, or replaces a completely different RF switch matrix, the adaptation function can be achieved simply by editing the text of the RF switch matrix configuration file. Compared with modifying the code, this method reduces the technical difficulty and is easier to use, thus greatly improving development efficiency.
[0093] In this embodiment, the matrix driving framework associates RF channel names with line loss tables in the form of RF switch matrix configuration files. When the test program calls various functions of the RF channel through the RF path object, such as changing the expected attenuation of the entire RF channel by adjusting the attenuation value of the adjustable attenuator in the RF channel, the matrix driving framework automatically associates the corresponding line loss table with the RF channel name and completes line loss value query, calculation, and automatic compensation in the background. Through this method, this embodiment can shield the cumbersome line loss compensation operation, freeing test software developers from focusing on line loss compensation and greatly simplifying the development process. Furthermore, when an external fixed attenuator is connected, it can be treated as an internal component and included without distinction through the RF switch matrix configuration file, making the matrix line loss function more adaptable.
Claims
1. A method for achieving compatibility and scalability in driving a radio frequency switch matrix, characterized in that, The method includes the following: Based on the component-level interface specification, the component-level programmable instructions of a specific RF switch matrix are encapsulated to form a component-level driver that conforms to the interface specification. Based on the component composition and cascade relationship of the RF switch matrix, and on the basis of meeting the configuration file format requirements, RF switch matrix resources and RF channel configurations are created to form the RF switch matrix configuration file; The matrix-driven framework is used to parse the RF switch matrix configuration file, dynamically create component resource objects and RF path objects, and implement application-level interface functions through the RF path objects. The test software calls the RF path object to achieve the decoupling process between the test program and the specific matrix control interface.
2. The method for achieving compatibility and scalability of RF switch matrix driving according to claim 1, characterized in that: When forming the RF switch matrix configuration file, the RF switch matrix resources also include an external fixed attenuator, and the RF channel configuration also includes a line loss table association.
3. The method for achieving compatibility and scalability of RF switch matrix driving according to claim 1, characterized in that: The matrix-driven framework is used to parse the resource composition information in the RF switch matrix configuration file, and based on the resource composition information, all component resource objects included in the RF switch matrix are dynamically created.
4. The method for achieving compatibility and scalability of RF switch matrix driving according to claim 3, characterized in that: The matrix-driven framework is used to parse the RF channels defined in the RF switch matrix configuration file and generate RF path objects. The RF path objects contain information on all components cascaded to the RF channels and control the components in the RF channels according to the component-level interface specifications to implement the relevant functions of the application-level interface.
5. The method for achieving compatibility and scalability of RF switch matrix driving according to claim 1, characterized in that: The matrix driving framework extracts the difference information between different RF switch matrices in the form of data. The difference information includes component category, component composition, component cascade relationship and component control information. When implementing application-level interface functions, the difference information is used as input parameters and processed by the matrix-driven framework to achieve consistency in processing logic.
6. The method for achieving compatibility and scalability of RF switch matrix driving according to claim 5, characterized in that: The processing code of the matrix driver framework is solidified. When adapting to the new model of RF switch matrix, the matrix driver framework encapsulates the component driver according to the component-level interface specification. The encapsulated component-level driver is used by the matrix driver framework in a direct calling manner.
7. The method for achieving compatibility and scalability of RF switch matrix driving according to claim 6, characterized in that: When a new RF channel is added to the RF switch matrix or when changes occur to the internal components that require modification of the driver, the extracted difference information data is modified.
8. The method for achieving compatibility and scalability of RF switch matrix driving according to claim 7, characterized in that: The RF switch matrix configuration file is saved in the form of a text file. The matrix driving framework will save the difference information between different RF switch matrices in the RF switch matrix configuration file in the form of a text file. When a new RF channel is added to the RF switch matrix or the internal components change, the text in the RF switch matrix configuration file can be edited to adapt it.
9. The method for achieving compatibility and scalability of RF switch matrix driving according to claim 8, characterized in that: In the RF switch matrix configuration file, when the test program calls the test function through the RF channel name, the matrix driving framework associates the RF channel name with the line loss information in the line loss table to complete the line loss value query, calculation and compensation operations.
10. The method for achieving compatibility and scalability of RF switch matrix driving according to claim 8, characterized in that: In the RF switch matrix configuration file, the test program creates RF channel objects by RF channel name, implements the switching of RF channels through RF channel objects, constructs the corresponding RF channels, and adjusts the attenuation value of the adjustable attenuator in the RF channels to change the expected attenuation of the corresponding RF channels.