Pickering Interfaces has raised the ceiling of its scalable LXI matrix line to 384×8 with the 65-217, a 2 A plug-in module that lets engineers grow switching capacity in a 19-inch, 2U chassis without pulling it from the rack. Each module contributes a 64×8, 1-pole matrix element, and up to six modules fit in the company's 65-200 LXI chassis.

The switching envelope is 300 VDC or 250 VAC at 2 A, with a maximum rating of 60 W or 62.5 VA per path. Ethernet control follows the LXI standard.

Why scalability matters here

Conventional high-density matrices force a purchase decision up front: buy the full matrix size or live with a smaller fixed block. The 65-217 approach splits that decision. Engineers start with one 64×8 module and add more as test requirements grow.

"The 65-217 gives users a practical way to start with the matrix size they need today and expand it later," said Steve Edwards, Head of Product Management at Pickering. "Up to six plug-in modules can be installed in a 65-200 chassis, creating a single matrix rather than separate 64×8 elements. The control software handles the path identification offsets between modules, reducing programming complexity."

That last point carries real weight for ATE programmers. When modules chain into one logical matrix, the driver absorbs the address offsets between physical plug-ins, so a test sequence written for a 64×8 system extends to 384×8 without rewriting path commands.

What does front access buy the maintenance schedule?

Modules load from the front panel. A failed or under-capacity matrix can be serviced or expanded without unbolting the chassis from the rack or re-cabling the rear, which is where most of the downtime in dense ATE installations actually accrues.

Spare relays mount on each plug-in, so a relay replacement needs no separate parts order. Two diagnostic layers support that strategy:

• Integrated BIRST (Built-In Relay Self-Test) detects failed or worn relays in place.
• Optional external eBIRST tools add the same coverage from outside the module.
• Relay cycle counting lets maintenance planners schedule replacement and deliberately balance usage across signal paths, spreading wear instead of concentrating it on favored routes.

For aerospace and automotive test programs running multi-year production, cycle-count-based maintenance planning converts relay wear from a random failure mode into a scheduled event.

Which applications drove the design?

Pickering specifies one demanding use case directly: RF crosstalk measurements on unterminated signal paths. This requirement appears in some aerospace and automotive applications, where the test system must route RF signals through paths that terminate at the device under test rather than at a defined instrument impedance. A matrix that behaves predictably in this regime needs careful attention to path bandwidth.

The Y-axis architecture addresses bandwidth two ways. Switched Y-axis loop-thru connections let the matrix span multiple 65-200 chassis, and switched Y-axis points can disconnect unused matrix sections entirely, so the active signal path sees less parasitic loading. Unused columns no longer tax the bandwidth of the columns in use.

A dual Y-axis analogue bus adds flexibility at the instrument boundary. Multiple external instruments can address different portions of the matrix simultaneously, or the bus can split the system into two independent matrices — effectively two smaller test subsystems in one chassis when a program needs parallel stimulus and measurement.

Configuration choices

Two versions ship: one with front-panel Y-axis access and one without. The front-panel variant suits bench development and debugging, where engineers probe Y-axis nodes directly; the rear-only version keeps the installed system's cabling clean.

The integration question

The 65-217's value depends less on any single specification — 2 A, 60 W, 384×8 — than on whether a test organization can absorb a modular chassis architecture into its existing racks and software. Teams already standardized on the 65-200 platform gain a growth path that preserves their program investment. Teams on monolithic matrices face the harder question: does the ability to buy switching capacity incrementally, and to service it from the front of the rack, justify a platform migration at the next system refresh?