在Win 7下的PNA上的TRL多端口校准

Jochen，虚拟设备是一种物理上不存在的设备。
一个例子是冲洗通过。
flush thru有一个s参数模型，S11，S22都等于0，S21，S12都等于1.当在校准套件中定义冲洗时，如果将其标记为虚拟设备，测量提示将显示“Connect”
当端口1和2之间连接有冲洗通道时，端口1到端口2“。如果不将其标记为虚拟设备，则测量提示将显示”在端口1和端口2之间连接INSERTABLE THRU STANDARD“。
总之，如果要建模的标准是物理设备，请不要选中虚拟设备复选框。
如果设备不是物理设备（如flush），请选中虚拟设备复选框。
如您所建议的那样，您应该能够指定校准类型。
如果您将校准套件中的连接器定义为性别，则可能会产生干扰。
如果是这样的话，两个端口对可以插入，一对端口不可插入。
例如，端口1是公头，端口2是母头，端口3是母头，校准套件仅定义了TRL kitclass映射的可插入标准，可以在1-3和1-2之间进行TRL，但不能在
2-3。
2-3的唯一选择是未知的通过。
顺便说一句，在所有端口对之间进行TRL并不会提高精度 - 它只会增加校准的复杂性。
存在多余的特征描述 - 您可能期望这些冗余会导致过度确定的解决方案，可能具有更高的准确性。
这不会发生*。
多端口校准序列被分解为1个或2个端口校准序列的子集。
它的排序方式是，如果校准步骤需要首先计算某些误差项，那么计算这些误差项的步骤将被适当地排序。
例如，考虑SOLT校准。
它包括每个端口上的单端口校准，然后是端口之间的已知直通校准。
您可以按任何顺序测量标准 - 例如，首先测量直通标准，然后测量单端口标准。
当涉及误差项的计算时，单端口校准计算在已知直通计算之前发生，因为已知直通计算依赖于由一端口校准标准计算的误差项的可用性。
TRL计算一对端口之间所需的所有错误条件。
这些错误术语可以被视为端口术语和路径术语。
端口术语是方向性，反射跟踪，源匹配和负载匹配。
路径术语是传输跟踪和可选的隔离。
当多个TRL校准触摸端口时，该端口的端口术语最终是由计算列表中稍后出现的TRL校准计算的端口术语。
对于多端口校准，不必在每个可能的端口对之间进行校准 - 校准包括每个端口所需的内容。
对于您的情况，默认序列将在两个端口对之间执行TRL，例如1-2和1-3。
这就是所需要的，可以从其他传输跟踪项计算2-3之间的传输跟踪。
如果你想添加一个额外的直通步骤，我会建议未知的直通。
未知的直通允许您最小化电缆移动。
电缆移动是最大的错误来源之一。
当我进行多端口校准时，我会安排一些事情，以便最大限度地减少电缆的移动。
例如，我将一端的偶数端口的电缆和另一侧的奇数端口的电缆。
我将定义一个校准序列，它只需要TRL或已知的奇数端口和偶数端口之间的校准。
然后，我会在奇数端口之间或偶数端口之间使用未知的直通校准，并且作为未知的标准，我将使用U形半刚性电缆。
这样我做了微小的扰动。
通常，电缆位置的起点应该是这样的，即当连接DUT时，需要最小的电缆移动。
应该利用未知直通选择校准，使得在校准期间不必从期望的DUT位置移动电缆。
Dave *注意：当我说校准没有利用冗余来计算超过确定的解决方案时，我的意思是在多端口级别，包括一个或两个端口的校准。
单端口校准本身可以利用过度确定的解决方案 - 单端口校准中的扩展校准是加权最小二乘解决方案，其基于其过度确定的性质而具有改进的性能。
此外，在将来的某个时刻，我们可以改进计算以利用多端口级别的过度确定的测量。



     以下为原文

  Jochen,

A virtual device is a device that doesn't physically exist. An example is a flush thru. The flush thru has an s-parameter model with S11, S22 both equal to 0 and S21, S12 both equal to 1. When defining a flush thru in a calibration kit if you mark it as a virtual device the measurement prompt will say "Connect port 1 to port 2" when there is a flush thru to be connected between ports 1 and 2. If you don't mark it as a virtual device the measurement prompt will say "Connect INSERTABLE THRU STANDARD between port 1 and port 2". In summary if the standard being modeled is a physical device don't check the virtual device checkbox. If the device is not a physical device such as a flush thru then check the virtual device checkbox.

As you suggested you should be able to specify the calibration type. Something that would interfere would be if you defined the connectors in the calibration kit as gendered. If so two of the port pairs could be insertable and one pair not insertable. For example, of port 1 is male, port 2 is female, and port 3 is female and the calibration kit only defined insertable standards for the TRL kitclass mapping it would be possible to do TRL between 1-3 and 1-2 but not between 2-3. The only option for 2-3 would be the unknown thru.

By the way, doing TRL between all of the port pairs does not improve the accuracy--it only increases the complexity of the calibration. There are redundant characterization that take place--you might expect that these redundancies contribute to an over determined solution with perhaps greater accuracy. This doesn't happen*. The multiport calibration sequence is broken up into subsets of 1 or two port calibration sequences. It is ordered in such a way that if a calibration step requires certain error terms to have been computed first the steps that compute those error terms will be ordered appropriately. For example, consider an SOLT calibration. It consists of a one-port calibration on each of the ports followed by a known thru calibration between the ports. You can measure the standards in any order--for example measure the thru first then the one-port standards. When it comes to computation of the error terms, the one-port calibration computation takes place before the known thru computation because the known thru computation relies on the availability of the error terms computed by the one -port calibration standards. TRL computes all of the error terms required between a pair of ports. These error terms can be thought of as port terms and path terms. Port terms are directivity, reflection tracking, source match and load match. Path terms would be transmission tracking and optionally isolation. When multiple TRL calibrations touch a port, the port terms for that port end up being those that were computed by the TRL calibration that came later in the computation list. 

For multiport calibrations it isn't necessary to do a calibration between every possible port pair--what is required that calibrations include every port. For your case, the default sequence would do TRL between two port pairs, say 1-2 and 1-3. This is all that is required, transmission tracking between 2-3 can be computed from the other transmission tracking terms. If you want to add an additional thru step, I would suggest the unknown thru. The unknown thru permits you to minimize the cable movement. Cable movement is one of the largest sources of error. When I do multiport calibrations I arrange things so I am able to minimize the cable movement. For example, I would put the cables for the even ports on one side and the cables for the odd ports on another side. I would define a calibration sequence that would only require TRL or known thru calibrations between an odd port and an even port. I would then use unknown thru calibrations between odd ports or between even ports and as an unknown thru standard I would use a u-shaped semi-rigid cable. This way I do minimal perturbation. In general, the starting point for cable position should be the such that when the DUT is connected minimal cable movement is required. Calibration should be selected taking advantage of the unknown thru such that the cables don't have to be moved from the desired DUT position during calibration.

Dave

*Note: When I said there calibration doesn't take advantage of the redundancies to compute over determined solutions I meant at the multiport level which is comprised of one or two-port calibrations. The one-port calibration itself can take advantage of an over determined solution--the expanded calibration in the one port calibration is a weighted least squares solution that has improved performance based on its over determined nature. Also, in the future at some point we may improve the computation to take advantage of over determined measurements at the multiport level.

戴夫，非常感谢您对多端口校准的详尽解释以及最小不确定度的有用提示。
很棒的是，您可以在多端口环境中通过cal方法混合TRL和未知。
因此，如果我将-dine标准定义为虚拟设备，那么PNA软件似乎会检查该标准是否为虚拟标准，并将其从要测量的标准列表中排除。
但是我不确定当你完成这个不完整的校准时会发生什么，其中只测量了反射和通过（没有尝试过）。
也许结果是三个端口之间的一堆规范化的cals？
我仍然想知道，但是，想知道“修改校准”对话框中出现的校准方法列表（在检查“修改校准：更改校准方法，标准”之后）是否在软件A.10.xx中是正确的。
在cal kit定义中，我不是指极化连接器，而是指无性别的波导。
如前所述，校准套件仅包含“穿透”，“线条”和“反射”。
GUI按预期提示TRL标准，但“修改校准”中的表在“通过校准方法”列中显示“未知通过”。
在软件A.9.xx中，它在相同的前提下表示“定义通过”。
约亨



     以下为原文

  Dave,

thanks a lot for your thorough explanation of multiport calibration and useful hints for minimum uncertainty. It is great that you can mix TRL and unknown through cal methods in a multiport environment.

So it seems that if I define -by mistake- a Line standard as virtual device, the PNA software checks that this standard cannot be virtual and excludes it from the list of standards to be measured. But I am not sure what happens when you finish this incomplete calibration, where only Reflects and Throughs have been measured (Didn´t try it). Maybe the result is a bunch of normalization cals between the three ports?

I am still wondering, wondering, however, whether the list of cal methods that appears in the "Modify Cal" dialog (after having checked "Modify Cal: Change Cal Method, standards") is correct in software A.10.xx. In cal kit definition, I do not refer to polarized connectors, but to a genderless waveguide. And the cal kit, as stated before, only contains Through, Line and Reflect. The GUI prompts for the TRL standards as expected, but the table in "Modify Cal" says "Unknown Through" in column "Thru Cal Method". In Software A.9.xx it said "Defined Through", under identical preconditions.

Jochen