The application leverages the Keysight instrument driver library to handle communication and control, while providing a user-friendly graphical interface (GUI) for remote operation. We also integrated the system with NI TestStand, creating a reusable set of custom steps that simplify sequence development.

System Overview

The goal was to design a flexible, modular system that allows an engineer or technician to:

• Configure measurement parameters for each instrument, using either the LabVIEW GUI or the onboard GUI of each device.
• Execute measurements automatically or under manual supervision.
• Collect and log results for analysis.
• Save and recall instrument states for repeatability.
• Integrate the entire workflow into automated TestStand sequences.

The core of the system is a LabVIEW application that acts as both the user interface and the instrument control framework. Each instrument is managed by its own dedicated driver class, responsible for communication, configuration, and data acquisition. All devices are connected to a controller PC that runs the LabVIEW application via LAN interface.

Using Keysight Instrument Drivers

Keysight provides certified LabVIEW drivers for many of its instruments. The libraries used in this application are as follows:

• RFSA: Keysight XSAn library
• RFNA: Keysight NA library
• RFPM: Agilent E441X Series library

These drivers implement a consistent API structure and follow the VISA standard, making them ideal for this type of automation project.

Our application created an Initialize, Calibrate, Configure, Acquire Data, Save/Recall Device State, and Close step for each device, using a parallel structure to the Keysight API for ease of integration. While these steps mirror the basic functionality of the VIs in the libraries, they allow the application to be more customizable by controlling only the settings we need to help streamline TestStand sequence development. The functions of each step are below:

• Initialize: This step creates an instrument handle that will be used by all other Keysight drivers in the device’s lifecycle
• Calibrate: This step allows the user to perform calibration and zeroing steps on the device (only for RFPM)
• Configure: This step allows the user to select specific settings for the measurements and sends them to the device
• Acquire Data: This step will perform a measurement using the settings specified in the previous step and export the data to the application
• Save/Recall Device State: This step allows the user to save or recall all device settings as a configuration file locally on the device’s drive (Only for RFSA/RFNA)
• Close: This step closes the VISA resource for the device to prevent any memory issues when the app closes

Application Design and Architecture

The LabVIEW application uses an object-oriented approach, with each device having a widget class, an abstract class, a Keysight instrument class, and a simulated class. The widget class uses APIs from the abstract class to call the basic steps listed above. Each widget also contains the GUI for device control from the LabVIEW front-end.

The Keysight instrument class contains device-specific drivers, and the simulated class generates random data when hardware is not available. If we replaced our devices with a non-Keysight model, we could easily add another class for that device’s drivers.

GUI Module

The GUI for RFSA has 2 screens, with users able to control basic display settings or recall a state from the device’s settings on the first screen. More settings options are available on the second screen, which is accessible by selecting the “Configure” button. After the user selects their desired settings, they can conduct a measurement using the “Start” button, then set markers using the frequency control or the slider below. The positions of the markers automatically update, and their frequency and amplitude values are displayed below.

The RFNA has a similar GUI but requires fewer settings. It has one screen, allowing the user to control the frequency range and select the test type between Insertion Loss (S12) or VSWR (S11). Like the RFSA, users can recall a device state, start a measurement, and control the marker from this screen.

The RFPM has a different GUI because it only conducts single-channel measurements, as opposed to frequency sweeps. This GUI allows the user to perform a calibration sequence by selecting the type (Calibrate, Zero, or Calibrate & Zero). The user can then select the frequency at which to conduct the measurement and set the resolution for the measurements. When the user selects the “Measure” button, the device conducts a power measurement and displays it both on the device’s onboard GUI and the LabVIEW GUI.

Data Acquisition and Storage

Measurements for each device can be conducted simultaneously, and the data from all three instruments can be automatically logged to local or network drives. For this application, the data is stored in a TDMS file format, but could easily be saved as a CSV or other format as well.

DMC implemented a data tagging system that associates each measurement with metadata such as date, time, operator, device under test (DUT) ID, and test sequence name. This metadata improves traceability and simplifies post-test analysis.

Integration with NI TestStand

DM added an additional layer of efficiency to the RF measurements by integrating them into NI TestStand sequences used across multiple test stations. To achieve this, we created custom TestStand steps that directly call the LabVIEW VIs controlling each instrument. Each step has a wrapper VI that is used to create a TestStand custom step. This allows the user to create sequences in TestStand the same way they would in LabVIEW, but without needing to understand the programming backend. When used in a sequence, the data plots appear in the report generated by TestStand, and the data can be used in pass/fail grading steps during the sequence itself.

TestStand is the foundation of one of DMC’s core battery test platforms for the reasons above and can enhance the accessibility of automation when used in conjunction with well-encapsulated LabVIEW code.

Conclusion

This project demonstrates how combining LabVIEW, Keysight instrument drivers, and NI TestStand creates a powerful and flexible RF measurement automation platform. By automating configuration, acquisition, and reporting for the three devices, we achieved significant gains in efficiency, repeatability, and scalability. The system meets current test requirements and lays the foundation for future automation initiatives. Because of the modular LabVIEW code, we can easily scale the system to add functions, GUI elements, and devices with minimal rework.

The post Automating RF Measurements Using LabVIEW for Keysight CXA, ENA, and EPM Instruments appeared first on DMC, Inc..

To overcome these limitations, our team designed a custom oscilloscope multiplexing system for differential signals, integrating PXIe switching hardware, custom cable harnesses, and a LabVIEW-based software interface. This solution enables users to route any of 12 differential signal pairs to a single oscilloscope for analysis while seamlessly passing the others through. The result is a flexible, automated, and low-noise measurement system tailored for differential signal measurements.

The Challenge

Our test system needed to monitor 12 independent differential signals originating from a high-speed digital subsystem. Each signal pair carried sensitive timing and amplitude information, and all were required to maintain integrity during routing.

The three primary challenges were:

1. Limited Oscilloscope Channels: The oscilloscope with the appropriate technical specification only supported two differential channels, far fewer than the 12 signals we needed to evaluate.
2. Signal Integrity: Because the signals were differential, maintaining tight impedance matching and minimizing skew between the positive and negative legs was crucial.
3. Automation Requirements: The test environment required fully automated control, eliminating manual reconnection of cables and ensuring repeatability across test runs.

This combination of constraints called for a custom, multiplexed routing solution—one that could dynamically connect any differential signal pair to the oscilloscope without degrading signal quality or requiring manual intervention.

Hardware Architecture

The foundation of our system is built with an NI PXI Chassis, PXIe switching cards, and an oscilloscope. The switching cards from NI and Pickering each contained a matrix of DPDT relays that are controlled using our custom LabVIEW application. Using DPDT relays was crucial for the design because each relay would link the positive and negative lines of each signal, ensuring that each signal’s switching was synchronized.

Signal Flow

1. Input Selection Tree: The twelve differential signals enter and exit our test fixture through the same custom harness connector. Each signal has one set of positive and negative lines for the input, and one set of positive and negative lines for the output, for 4 in total. The input lines of the desired signal enter the Pickering relay card and pass through a series of relays to route to the oscilloscope, creating a selection tree. The remaining eleven signals bypass the tree and go through the bypass path, which can then be optionally connected to a DMM, test fixture ground, or DUT (Device Under Test) ground as desired.
2. Oscilloscope Measurement: The desired signal to measure passes through a 2 channel PXI Oscilloscope. The first oscilloscope channel would measure the positive signal line and ground, and the second channel would measure between the negative signal line and ground. This allows the user to view the components of the differential signal individually or view the total output by creating a math channel.
3. Output Selection Tree: Just like the input side of the tree, the signal is routed from the oscilloscope to the output side of the custom harness connector. This allows the signal to be used elsewhere as opposed to terminating within the test fixture. The symmetry of the system is also critical for maintaining signal integrity.

Each relay closure is software-controlled, allowing instantaneous switching between signals without physically altering connections. The process is automated, so a user only needs to select a signal to route, and all the associated relay states will automatically change to reflect this, instead of manually setting relay states.

Custom Cable Harness Design

A significant part of the project involved developing the custom cable harnesses that interfaced the DUT signals with the PXI cards and oscilloscope.

Because we were dealing with differential signals, cable symmetry and shielding were paramount. Each harness was constructed using shielded, twisted cables for each signal. This helped to reduce cross-talk between different signals in the harness. At the connection to the switch cards, several of the pins were shorted together, creating the paths among the different relays for the selection trees. Our harnesses also contained an internal resistor that could be used to terminate the signal after the oscilloscope, instead of routing it to the output. This could be used to simulate the presence of a different load on the output end if that hardware were not present.

Harness Concerns

1. Input/Output Connectors: The harnesses utilized high signal integrity D38999 connectors for the signal input/output connectors to ensure the best possible signal integrity and compatibility without a DUT. The PXI connectors were 160-pin arrays that could connect all of the DPDT relay inputs and outputs, with plenty of space in the connector for internal pin-pin connections.
2. Cable Routing: The cables were designed to minimize total length and bend as much as possible. Length and bending could have drastic effects on the signal integrity and could damage the internal wires.
3. Shielding: All signals were routed using shielded, twisted cables. The shields were all tied together with a grounding screw to the shells of all connectors, where they would then make contact with the test fixture ground connection. This design ensured the most reliable signal integrity during later testing.

The result was a harness system that preserved the integrity of high-speed differential signals even through multiple routing layers.

Software Control with LabVIEW and Pickering Drivers

On the software side, we implemented the routing logic and user interface using a LabVIEW application. The app incorporates the Pickering pipx40 VISA driver library and the NI Switch library. Additionally, we created custom steps to be used in an automated TestStand sequence for automatic control within the LabVIEW application.

Signal Tree UI

The UI for the selection tree shows all 12 signal inputs/outputs, as well as connector and PIN numbers. Using the “Signal Selection” and “Terminating Resistor On” controls will route the intended signal through the tree and can also add the harness’s built-in terminating resistor if desired. The UI also provides a visual representation to the user. For signals passing through the bypass path, the two busses in the middle allow the user to connect individual lines to the DMM leads or the different system grounds.

Safety Features

The UI also has built-in safety controls to prevent short circuits from damaging sensitive hardware. The UI does not allow multiple signal pairs to be routed through the oscilloscope simultaneously. If a user attempts to connect a second signal, the first signal will first be disconnected from the oscilloscope, and the UI will update to reflect this. Additionally, the bypass path busses in the middle do not allow multiple items to connect to the same bus, as this could also lead to shorting different signal lines together.

Maintaining Differential Signal Integrity

One of the most critical aspects of the design was ensuring differential signal integrity through the entire multiplexing path. Switching and routing introduce potential sources of error such as impedance mismatch, crosstalk, and common-mode noise.

To minimize these effects, we implemented several design strategies:

1. Matched Differential Paths: Both legs of each differential pair were routed symmetrically, including through the PXIe switch card traces. When viewing the oscilloscope measurements with terminating resistors, the data was noticeably more distorted than when routing symmetrically.
2. Connector Pinouts: When designing the harnesses, the component selection was not the only important factor in signal integrity. The pin locations on the input and output connectors had a large effect. Placing the positive and negative lines of a signal too far apart created more crosstalk between different signals, so it was vital to place the positive and negative pins of each signal on adjacent pins. Conversely, it was important to keep the input pins far from the output pins. This would tend to create more uniformity between the positive and negative signals.
3. Short Routing Paths: The layout minimized total signal length and avoided cable bends as much as possible. This puts less strain on the cable and increases signal integrity.
4. Relay Selection: Pickering’s DPDT relays were chosen for their low insertion loss, excellent channel-to-channel isolation, and consistent contact resistance.

After assembly, the system was validated using a custom LabVIEW application for measuring signal integrity, with more info on that found here: Creating Eye Diagrams using LabVIEW Jitter Analysis.

Results and Performance

The completed system successfully allowed any of the 12 differential signals to be routed to the oscilloscope in under 100 MS, with no measurable degradation in signal amplitude or timing. Signal skew between differential lines was consistently below 10 PS, and insertion loss was negligible across the frequency range of interest.

Users reported significantly improved workflow efficiency, with no more manual re-cabling, reduced setup time, and fully automated test runs. The system has been integrated into both R&D and production environments, where it continues to provide reliable, flexible differential signal monitoring.

Lessons Learned

Developing a multiplexed oscilloscope system for differential signals highlighted several key insights:

1. Signal Integrity Comes First – Hardware design decisions must prioritize impedance control and symmetry from the outset.
2. Modular Design Simplifies Expansion – The PXI platform made it easy to expand from 8 to 12 channels by adding another matrix module.
3. Software Flexibility Adds Value – The ability to automate and visualize routing in LabVIEW dramatically improved usability and test throughput.

Conclusion

By combining PXI hardware, precision cable design, and a LabVIEW control interface, we developed a custom oscilloscope multiplexing solution capable of routing 12 differential signals to a single measurement instrument. This approach preserved signal integrity, reduced manual intervention, and enabled fast and automated analysis of high-speed differential waveforms.

The system demonstrates how thoughtful integration of modular hardware and flexible software can overcome real-world measurement challenges. Whether used in validation labs or automated test stands, custom multiplexing architectures like this can extend the capabilities of existing oscilloscopes and simplify complex signal analysis tasks.

The post Custom Oscilloscope Multiplexing for Differential Signals appeared first on DMC, Inc..

Generating a Proper Signal

To create an eye diagram, a digital signal is required. Eye diagrams overlay multiple bit transitions on a single plot to show how the signal transitions between high and low bits. A good signal for eye diagrams will contain at least one occurrence of every possible 3-bit sequence (000, 001, 010,…). The easiest way to automate this process is to send a data signal of 0000 0101 0011 1001 0111 0111 continuously and measure the waveform with an oscilloscope. The datatypes available to use are DBL or I8. The waveform data can either be sent directly to the eye diagram generator or saved to a .csv or .tdms file and processed later into an eye diagram.

Creating Eye Diagrams in LabVIEW

The first step in creating an eye diagram in LabVIEW is to install the LabVIEW Jitter Analysis Toolkit. Once that is installed, the necessary VI’s can be found by right-clicking, then Addons -> Jitter Analysis. Creating an eye diagram will use VI’s from the “Level”, “Timing”, “Clock Recovery”, and “Eye Diagram” groups to find the transitions, level crossings, and reference levels, then format into a diagram.

Reference Levels

The Reference Levels VI is the first data processing step. For this application, the “waveform in” option is used with the appropriate data type selected. This VI is used to determine the voltage of the HI and LO states (state levels), and the voltage at which it registers a transition (reference levels). The state-level settings and reference-level settings are not required, but they can be used to configure how the levels are detected. The state-level settings allow the user to configure if the HI and LO are determined by a histogram (default), which sorts waveform points into the upper and lower 40% to determine the state levels. The reference levels settings allow the user to configure whether the reference levels are determined by a percent of the state levels or by an absolute voltage. The state levels and reference levels determine where the waveform is segmented for state transitions.

Find Transitions

The Find Transitions VI is used to find the transition points between states in the input waveform. Using the state levels and reference levels from the previous step alongside the waveform, it parses through the waveform data and finds the points at which the voltage crosses the high and low reference levels. The transitions output contains an array in which each element has a start index, stop index, and rising/falling edge indicator. The transitions output also contains duplicates of the state levels and reference levels to be used in future steps.

Level Crossings

The Level Crossings VI is a polymorphic VI found in the “Timing” group of the Jitter Analysis Toolkit. For this application, the “transitions in” option is used with the appropriate data type selected. It is important to note that selecting the “levels in” option is possible and would combine the functionality of the Find Transitions and Level Crossings steps into one VI if desired. This VI finds the points at which the waveform crosses the specified crossing level. If no input is supplied, the mid reference level will be used instead. The level crossings output contains an array of all the indices at which the waveform crosses the crossing level and its slope.

Clock Recovery

The Clock Recovery VI synchronizes the waveform to a recovered internal clock using a best fit of the reference to the level crossings. The ref level crossings output is the same data type as the level crossings output. Its indices array contains synchronized points at which the waveform crosses the mid reference level. The unit interval is also the best fit duration in seconds of one single bit of data in the waveform. Both the ref level crossings and unit interval are used in the next setup, creating the eye diagram data.

Eye Data Generation

The Eye Data Generation VI creates the histogram that will be used to make the final diagram. The eye diagram data cluster contains a 2D array of histogram data, along with an array of the start and end indices of each segment on the plot. It also contains scaling information about the minimum and maximum time and voltages that will be used in the plot. The resolution control changes how many histogram bins will be dedicated to the time and voltage axes. This corresponds to the number of pixels that will be used in the x and y axes of the final plot. The default setting is 400×200.

Eye Height and Width

The Eye Diagram Height and Width VI calculates the height at the location specified by the time input. The time input is the percent along the unit interval at which the measurement will be taken, with the default value being 0.5. The width is measured at the voltage specified by the level input. If the input is blank, the default value is the mid ref level from the Reference Levels VI. Both the height and width are calculated by finding the mean upper and lower bounds, 3 standard deviations from their means, and finding the difference between them. The height and width are both outputs of the vi, and also a part of the eye diagram data out cluster. This VI is not necessary in plotting the eye diagram, but important for determining quantitative results.

Eye Diagram Support

The Eye Diagram Support VI extracts the histogram data as a 2D array scaled from 0 to 1. Because the histogram is a 3D representation of data, the value of each element in the array represents the intensity of the signal integrity at that pixel of the final graph. This VI allows the user to plot the height/width as well. Enabling this will plot a cross centered at the center of the graph, with the height and width determined by the previous step. The better the signal integrity is, the bigger the cross will be. The VI also outputs the x and y scales, which are used to set the x and y axes of the resulting graph.

Eye Color and Scale Generation

The last jitter analysis step is the Eye Color and Scale Generation VI, which allows the user to adjust the color appearance of the graph. The color settings control allows the user to determine the color mapping type, hue, and background color. The default (shown in the example picture) is a single hue mapping type, with a dark blue hue (#0003b4) and a black background (#000000). This means that the lower-intensity histogram values appear in dark blue, and the higher-intensity values appear in white. Changing the mapping to rainbow hue will map the higher intensity values in the selected hue color, and the lower intensity values as far from the selected color as possible, resembling a heat map. The output marker values are an array of the colors that will be used based on the selected inputs. This will be used in the property node to control the final plot. It is important to also set the ignore array property to false, otherwise the colors selected will be overridden with the default instead.

The post Creating Eye Diagrams Using LabVIEW Jitter Analysis Toolkit appeared first on DMC, Inc..