MSOX3000采样时钟触发偏移？

这里有两个问题： - 触发抖动 - 每个示波器都有一些触发抖动，这意味着交叉点不会通过屏幕中心，而是接近它。
更高性能（和更高成本）范围指定触发器抖动，并且非常努力地减少它。
- 采样偏移 - 采样器与触发器不同步，因此最接近触发器的采样将永远不会在0ps，而是最多1个采样周期。
该时间偏移应该作为序言中的第6个字段，如Xorigin。
你也可以从WAV：XOR获得它？
查询。
即使该值也会有一些不确定性，因为触发插补器并不完美。
使用范围数据进行波形平均是一门艺术，并非易事。
上述问题意味着你不能只说，例如，“我将采取所有的第一个样本并对它们进行平均，然后是第二个样本...”您可能需要对所有波形进行插值和重采样
在平均它们之前删除时间偏移量。
祝你好运！
人



     以下为原文

  There are 2 issues here:

- Trigger Jitter - every scope has some trigger jitter, meaning that the crossing won't go through the center of the screen, but close to it. Higher performance (and higher cost) scopes specify the trigger jitter, and work very hard to reduce it.

- Sample offset - The sampler is asynchronous to the trigger, so the sample closest to the trigger will never be right at 0ps, but up to 1 sample period away. That time offset should be available as the 6th field in the preamble, as the Xorigin. You can also get that from the WAV:XOR? query. Even that value will have some uncertainty, since the trigger interpolator isn't perfect.

Waveform averaging with scope data is a fine art, and not an easy thing to do. The above issues mean that you can't just say, for instance, "I'm going to take all of the first samples and average them, then the second samples..." You might need to interpolate and resample all of the waveforms to remove the time offsets before you average them.

Good Luck!

Al

嗨Al，感谢您的快速反应。
正如你所说，我的攻击计划是重新取样然后平均。
我没有找到X3104的触发抖动规格，但基于快速边缘的眼球，它看起来比采样间隔好一个数量级。
我无法关闭sin（x）/ x插值，因此可能会有一些伪影散布出交叉。
该范围的Xorigin永远不会从采集变为采集，即使它以足够的精度（例如，“ - 2.50000000E-009”）打印以表示来自触发插值器的偏移。
设置延迟_does_会影响Xorigin，但一旦设置它就是静态的。
事实上，序言中没有任何内容在连续的收购中发生变化，这就是我开始寻找其他地方的原因。
也许该模型外部无法使用触发插补器值？
或许它被错误地排除在Xorigin之外？



     以下为原文

  Hi Al,

Thanks for the speedy response.

My plan of attack is as you say, to resample and then average.

There's no trigger jitter spec I can find for the X3104, but based on eyeballing a fast edge it appears to be about an order of magnitude better than the sample interval.  I can't turn off sin(x)/x interpolation, so there may be some artifacts from that too that's spreading out the crossing.

The Xorigin on this scope never changes from acquisition to acquisition, even though it's printed with plenty of precision (e.g., "-2.50000000E-009") to represent the offset from the trigger interpolator.  Setting the delay _does_ affect the Xorigin, but once set it is static.  In fact, nothing in the preamble changes in successive acquisitions, which is why I started looking in other places.

Maybe the trigger interpolator value is not available externally on this model?  Or maybe it was mistakenly left out of Xorigin?

您的问题有两种解决方案。
1）使用更好的范围。
Infiniium示波器具有更多功能，可能更适合您尝试进行的测量。
2）在进行平均之前，请进行自己的插值并消除触发抖动。
人



     以下为原文

  There are 2 solutions to your problem.

1) Use a better scope. The Infiniium scopes have many more capabilities, and are probably more suited to the measurements that you are trying to make.

2) Do your own interpolation and remove the trigger jitter before you do the averaging.

Al

有机会再多看一下，结果发现触发插补器偏移用于计算原始波形中返回的点（当没有显示整个波形时）。
通过将触发区域重新定位到返回波形的前几个点，可以继续将时基位置值减小20ps（3000X上允许的最小增量），直到第一个点从返回的波形下降（即电压值）
变化）。
当发生这种情况时，您发现内插器偏移到+/- 20ps。
初始结果在这些范围内，因此触发抖动似乎非常低。
显然，这是对单次捕获的所有后处理，然后根据需要重复多次。
这个过程很慢，无可否认是一个黑客，但它会得到我正在寻找的数据。
这种特殊的衡量标准属于“如果我们能做到这一点就会很棒”，并且它并不能证明在更高级别范围内进行投资是合理的。
但我仍然建议将插值器值添加到某个命令。
范围知道这个数字，它应该公开它供程序使用。
谢谢你的建议，Al。
它让我想到了这种替代方法。



     以下为原文

  Had a chance to look at this a little more and it turns out the trigger interpolator offset is used in the calculation of which points are returned in a raw waveform (when the whole waveform is not being displayed).

By repositioning the trigger area to the first few points of the returned waveform, it's possible to continue decrementing the timebase position value by 20ps (the minimum delta allowed on the 3000X) until the first point falls off the returned waveform (i.e., the voltage value changes).

When that happens, you've found the interpolator offset to +/-20ps.  Initial results are within these bounds, so trigger jitter appears to be very low.

Obviously this is all post processing on a single shot capture, which is then repeated as many times as needed.

The process is slow and admittedly a hack, but it will get me the data I was looking for.  This particular measurement was in the category of "it would be great if we could do it", and it didn't really didn't justify an investment in a higher class scope.

But I would still suggest the interpolator value be added to a command somewhere.  The scope knows this number and it should expose it for programs to use.

Thanks for your suggestions, Al.  It got me thinking about this alternate approach.