PNA-X CW Time什么是真正的分辨率？

在一个完美的世界里，你的数学是正确的。
欢迎来到真实的世界！
这方面的专家一直到星期一，所以这是我对此的看法。
希望我不会太不准确......如果我是，我会请他纠正这个。
首先，你似乎有较旧的DSP（SPAM）板，因为较新的板将达到15MHz IFBW，所以我的结果将与你的略有不同。
虽然可以在200ns时间窗口上获取数据，但是涉及相当大的开销。
在频率超过250KHz的IFBW上，PNA处理跟不上快速的DSP输出。
还有其他数据流程会增加实际的数据显示。
因此，在每个200ns处取11个点将不会产生2.2us的扫描时间。
对于使用CW，5MHz IFBW和11点的PNA，我看到显示的停止时间为1.65uS。
显示屏开启时*实际*扫描时间约为6.9mS，显示屏关闭时约为1.5ms。
所以，是的，1500us与2.2us理论相去甚远。
我假设在显示的1.65uS期间实际数据取+ +出现但我会让专家在他返回时对此进行评论。



     以下为原文

  In a perfect world, your math would be correct.  Welcome to the real world!  The expert on this is gone until Monday, so here is my take on this.  Hopefully I will not be too inaccurate....and if I am, I will ask him to correct this.

First, you appear to have the slightly older DSP (SPAM) board since the newer ones will achieve 15MHz IFBW, so my results will be slightly different than yours. 

While the data may be taken over a 200ns time window, there is a fair amount of overhead involved.  At IFBWs much over 250KHz, the PNA processing cannot keep up with the rapid DSP output.  There are other data processes going on that will increase the actual display of data.  So taking 11 points at 200ns each will not result in a 2.2us sweep time.  

For my PNA using CW, 5MHz IFBW, and 11 points, I see a displayed Stop time of 1.65uS.   The *actual* sweep time is about 6.9mS with the display on, and about 1.5ms with the display off.  So, yes, 1500us is a far cry from the 2.2us theoretical.  I assume the actual data taking +does+ occur over the displayed 1.65uS period but I will let the expert comment on this when he returns.

Jvall比你的内心。
是的，在那个系统中肯定存在一些问题我正在寻找的最重要的答案是标记步的1.46ns值是否真实，或者它只是基于屏幕分辨率的跟踪的插值。
因此，如果我必须测量100ns的切换时间，我是否需要列出20MHz的IFBW？
我想知道噪声系数接收器是否可用于此，我认为它可以设置为20MHz。
让我们看看专家建议的内容。



     以下为原文

  Jvall

Than you for the insides.  Yes there is definite some over head in that system

The most important answer I am looking is if that 1.46ns value of marker step is real or it is just interpolation value of the trace base on screen resolution.
So if I have to measure switching time of 100ns, do I need at list 20MHz IFBW?
I wonder if the Noise Figure Receiver can be use for that, I think it can be set to 20MHz.

Let see what the expert suggest.

一旦你开始谈论标记，这会变得有点复杂。
这是由于一个sorta-bug（或更确切地说，一个定义问题。）所以对于简单的部分（这可能与我之前所说的相矛盾），显示的停止时间应该是准确的...至少IFBW高达约
250kHz，甚至可能高于250kHz;
我需要确认一下。
你可能没有得到你期望的确切时间（由于一些技巧），但时间应该是准确的。
与我之前所说的不同，*从一个数据桶的末尾到下一个数据桶的开头没有时间延迟*。
数据是连续的。
该数据的显示可能需要一点但是对于任何给定的扫描，采集是连续的。
我们将忽略回溯时间。
*现在，对于标记：*假设CW为3点，1kHz IFBW。
确保标记设置为离散标记。
扫描的开始是0.0，理论上结束是3ms;
虽然我显示了2.8ms（记得我说过的技巧）。
我将假设下面的总时间为3毫秒。
您只能将标记放在迹线的开头，中间和末尾。
在时间方面，标记将显示0,1.5或3ms。
0ms读数是第一次数据采集的* START *。
3ms读数是上次采集的* END *。
中间1.5毫秒的值几乎没有意义。
实际起始值应为0,1和2ms。
结束值应为1,2和3毫秒。
我们不允许您选择要显示的内容，这会导致整体混乱。
通常，在处理大量点时这不是什么大问题，因为实际误差非常小，但只有几点，您会遇到试图将单个数据点显示为一条线的问题。
那么我们应该展示什么？
显然，我们一直在争论如何正确地显示这些多年。
我希望这会有所帮助，但它可能会让问题更加混乱！



     以下为原文

  This gets a bit complex once you start talking about markers.  This is due to a sorta-bug (or more precisely, a definition issue.)

So for the simple part (which may contradict what I said before), the displayed Stop time should be accurate...at least with IFBWs up to about 250kHz, and possibly even above that too; I will need to confirm this.  You may not get the the exact time you are expecting (due to some tricks) but the time should be accurate.  Unlike what I said before, there *is NO time delay* from the end of one data bucket to the beginning of the next.  The data is taken continuously.  The display of that data may take a bit but the acquisition is continuous for any given sweep. We are going to ignore retrace time.

*Now, for markers:*
Let take the case of CW with 3 points with 1kHz IFBW.  Make sure the marker is set for discrete markers.  The start of the sweep is 0.0 and the end is theoretically 3ms; although I show 2.8ms (remember what I said about tricks.).  I am just going to assume 3ms total time for the below.

You can only place the marker at the beginning, exact middle, and end of the trace.  Time-wise, the marker will display  0, 1.5, or 3ms.   The 0ms reading is the *START* of the first data acquisition.  The 3ms reading is the *END* of the last acquisition.  The middle 1.5 ms value is pretty much meaningless.  The actual start values should be 0, 1, and 2ms.  The ending values should be 1, 2, and 3ms.  We do not allow you to chose which to display, and that leads to the overall confusion.  Normally this is not a big deal when dealing with large number of points, as the actual error is very minor, but with just a few points, you run into issues trying to display a single data point as a line.

So what should we display?  Apparently we have been arguing over how to display this properly for years.  I hope this helps, but it will probably just confuse the issue even more!

这里有很多事情：1）DSP4上5MHz滤波器的CW时间扫描分辨率为133.33 nS。
每个点的实际采集时间为266.67 nS，但我们将它们重叠用于CW时间扫描。
2）您的标记分辨率太小，因为标记在点之间进行插值。
要禁用此功能，请将标记置于“离散”模式。
3）你仍然不会得到133.33 nS，因为我们的代码中有一个jvall提到的错误。
我从点到点得到146.67 nS。
与1001点扫描一样，您可以通过转到很多点来减少此错误。
我会看看是否可以提高修复此错误的优先级。
它很复杂，因为定义不明确。
4）我们的硬件触发仅适用于外部触发输入。
我们目前无法触发测量的RF信号本身。
5）x轴上的时间0与触发器进入时的时间不对应。它对应于我们开始获取数据的时间。
我们有一些触发延迟。
你测量的是什么样的切换时间？
它是否与控制信号有关，例如TTL线？
或者你是否测量了10％到90％的开启时间？



     以下为原文

  There are a number of things going on here:

1) The CW time sweep resolution for the 5MHz filter on a DSP4 is 133.33 nS. The actual acquisition time for each point is 266.67 nS, but we overlap them for CW time sweeps.
2) You are getting a marker resolution way too small, because the marker is interpolating between points. To disable this, put the marker into "discrete" mode.
3) You still won't get the 133.33 nS because of a bug in our code that jvall alluded to. I get 146.67 nS from point to point. You can reduce this error by going to a lot of points, as you did with the 1001 point sweep. I will see if I can increase the priority of fixing this bug. It is complicated because the definition is not clear.
4) Our hardware triggering only works on the external trigger input. We currently have no way to trigger on the measured RF signals themselves.
5) Time 0 on the x-axis does not correspond to when the trigger comes in. It corresponds to when we start taking data. We have some trigger latency.

What kind of switching time are you measuring? Is it relative to a control signal, such as a TTL line? Or are you measuring a 10% to 90% turn on time?

HI Mirek，你可以决定：选择是：1）开始时间总是零，停止时间是（点数）x（IF获取时间）。
因此，对于1 MHz（1 usec）和10点，开始时间为0，停止时间为10 usec 2）开始时间始终为IF采集时间，停止时间是最后采集后的时间或（开始时间）+点
*（IF acq time），ex，start 1usec，stop 11 usec 3）分割差异：开始时间= 0.5 usec，停止时间= 10.5 usec在所有情况下，离散标记将精确地增加IF分辨率。
Niels指出，在最宽的带宽中，我们实际上重叠了acquisitoins以获得CW分辨率的2倍，但这并不会影响x轴上的一次性错误。
所以，现在是时候了，在PNA实施上留下自己的印记！
附：
对Niels来说......你知道，你知道，它最终会成为一个偏好！



     以下为原文

  HI Mirek, you get to decide:

The choices are: 
1) Start time is always zero, stop time is (number of points) x (IF acquisiton time).  Thus, for 1 MHz (1 usec) and 10 points, start time is 0, stop time is 10 usec
2) Start time is always the IF acquistion time, stop time is the time after the last acquistion or (start time )+ points*(IF acq time), ex, start 1usec, stop 11 usec
3) split the difference:  Start time = 0.5 usec, stop time =10.5 usec

In all cases, discrete markers will increment in exactly the IF resolution.

Niels points out that in the widest bandwidths, we actually overlap acquisitoins to get 2x the CW resoluton, but this doesn't effect the goofy off-by-one time error on the x-axis.

So, now's the time, make your mark on the PNA implementation!

P.S. to Niels... you know, you just know, it's going to end up a Preference!

我相信尼尔斯昨天已经提到了这个结论！
哦，还有一个偏好！



     以下为原文

  I believe Niels already alluded to that conclusion yesterday!
Oh well, what's one more preference!

> {quote：title = nielsj写道：} {quote}> 4）我们的硬件触发仅适用于外部触发输入。
我们目前无法触发测量的RF信号本身。
>您测量的是什么样的切换时间？
它是否与控制信号有关，例如TTL线？
或者你是否测量了10％到90％的开启时间？
我相信JP可以在FPGA中解决这个问题！
只需监控ADC读数，直到它足够大然后开始处理......还有一件事要做，嗯？



     以下为原文

  > {quote:title=nielsj wrote:}{quote}

> 4) Our hardware triggering only works on the external trigger input. We currently have no way to trigger on the measured RF signals themselves.
 
> What kind of switching time are you measuring? Is it relative to a control signal, such as a TTL line? Or are you measuring a 10% to 90% turn on time?
I'm sure JP could sort that out in the FPGA! Just monitor ADC reads until it is big enough then start processing...just one more thing to stuff in, eh?

感谢您的投入。
我需要测量的确切事项是开关的稳定时间。
我按照应用说明：“了解射频/微波固态开关及其应用”非常好的材料，可以更新以适应更新的设备，如具有宽实时带宽的PXA / MXA频谱分析仪或E5052B信号源分析仪。
回答Niels问题：我需要测量的稳定时间在100ns到300ns之间。
我有几个带有5MHz带宽的PNA-X N5242A，我还有一个带15MHz带宽的PNA-X N5244A。
甚至15MHz BW看起来也很慢，因为它的分辨率约为66ns。
说到我拥有的E5052B信号源分析仪。
看起来它可能比PNA-X网络分析仪更好。
E5052B的规格称其具有250Mhz带宽，8n分辨率！
现在的问题是如何连接触发器（输入或输出），使用什么功能以及如何设置该功能。
是否需要连接来自源的10Mhz参考？
如何触发测量？
来自DUT的RF频率约为1600MHz，脉冲可能不会快于10KHz。



     以下为原文

  Thank you for the inputs.

The exact thing that I need to measure is Settling Time of the switches.
I follow the Application note: "Understanding RF/Microwave Solid State Switches and their Application"
Very good material, could be updated to accommodate newer equipment like PXA/MXA Spectrum Analyzer with wide real time bandwidth or E5052B Signal Source Analyzer. 
To answer Niels question: The settling time that I need to measure is between 100ns to 300ns.

I do have couple PNA-X N5242A with 5MHz bandwidth, I also have one  PNA-X N5244A with 15MHz bandwidth.
Even 15MHz BW look like to slow for the measurement as it will have around 66ns resolution.

Speaking about E5052B Signal Source Analyzer that I have. It look like it might be even better then the PNA-X Network Analyzer. The spec for E5052B saying that it have 250Mhz bandwidth with 8n resolution!!! 
Now the question is how to connect trigger (input or output), what function to use, and how to set that function. Does the 10Mhz reference from source need to be connected?
How to trigger the measurement?
The RF frequency from DUT will be around 1600MHz with pulse probably not faster then 10KHz.

如果将开关设置为重复切换，则可以使用窄带模式并获得10 ns的分辨率。
我附上了内部产生脉冲测量值的图片。
是的，关断时间比开启时间慢（仅仅是脉冲驱动器的结果）。



     以下为原文

  If you setup your switch to be switched repetitively, you can use the narrow-band mode and get resolutions of 10 ns.  I've attached a picture of the measuerment of our internally generated pulse.  And yes, the turn-off time is slower than the turn on time (just a result of the pulse driver).

附件

• PulseRise.PNG76.2 KB
  

Joel 10ns非常好。
附加图片......看起来像在服务器的某个地方丢失了。
问候，



     以下为原文

  Joel
10ns that pretty good.
The attach picture...look like is lost to the history somewhere in the server. 

Regards,

在这里，我尝试重新连接脉冲测量。
你可以在这里看到我的上升时间。



     以下为原文

  Here I tried to re-attached the pulse measurement.  You can see my risetime here.

附件

• PulseRise.PNG76.2 KB
  

Dr_joel当我第一次看到那张照片时，我没有意识到它是来自PNA-X，而不是来自E5052B信号源分析。
窄带模块在哪里？
我该怎么设置？



     以下为原文

  Dr_joel

When I first see that picture I did not realized that it is from PNA-X not from E5052B Signal Source Analyze.
Where is that narrow-band mod? How do I set that?

你必须有脉冲测量应用程序，选项008.然后转到脉冲轮廓并在高级选择窄带下。



     以下为原文

  you must have the pulse measurement application, option 008.  Then go to pulse profile and under the advanced select narrowband.