可变突发长度数据的数字捕获

我假设您可以重复错误条件。
如果数据包的序列相当一致，您可以在整个SPI活动突发的多个触发器上手动构建记录，而不是使用分段。
使用“单个”而不是“运行/停止”，这会使记录长度加倍。
将时间/格设置为最慢可能，以便解码仍然有效（没有粉红色表示欠采样）。
将触发器设置为第一个数据包，将水平时间参考设置为“Left”。
生成错误条件并查找错误。
然后将延迟移动几乎全屏（可能是9格）。
再次运行测试。
继续增加延迟。
有点乏味，但它是一种解决内存限制的方法。



     以下为原文

  I assume you can repeat the error condition.  If the sequence of the packets is fairly consistent you can manually build the record over multiple triggers of the entire burst of SPI activity instead of using segmented.  Use 'Single' instead of 'Run/Stop' which doubles the record length.  Set the time/div to the slowest possible so that the decode is still valid (no pink which indicates undersampled).  The set the trigger to the very first packet and the horizontal time reference to 'Left'.  Generate the error condition and look for the error.  Then move the delay by almost a full screen (maybe 9 divisions).  Run the test again.  Keep adding delay.  Somewhat tedious but it is a way to get around the memory limitations.

你可能应该做'Thomas001'所说的......在一系列捕获中构建跟踪。
至于ScanaPLUS，它看起来很有趣，但有些限制。
虽然有协议解码器，但除了简单的边缘触发器之外没有触发器。
正如您所说，看起来它可以捕获，但前提是捕获的数据可以被压缩。
当与随机数据一起使用时，不清楚深度是多少。
我可以看到，在某些情况下，它可能非常有用。
也许您可以在分段模式下使用示波器，并将Trigger Out连接到ScanaPlus上未使用的通道，以便您可以轻松找到每个数据包的开头。
免责声明：为了获得更可靠的响应，您应该考虑致电当地的Keysight技术呼叫中心。
Keysightwilliam hill官网 在“可用”的基础上进行监控，并不一定是解决技术问题的最快方式。



     以下为原文

  You should probably do what 'Thomas001' says.. Build the trace over a series of captures. 

As for the ScanaPLUS, it looks very interesting, but somewhat limited. While there are protocol decoders, there are no triggers, except for simple edge triggers. It looks like it can capture, as you said, but only if the captured data can be compressed. It's unclear what the depth is when used with random data. I can see that for some situations, it can be quite useful. Maybe you can use the scope in segmented mode, and connect the Trigger Out to an unused channel on the ScanaPlus, so that you can easily find the beginning of each packet.

Al

Disclaimer: For more reliable response, you should consider calling your local Keysight Technical Call Center. The Keysight Forums are monitored on an "as available" basis, and aren't necessarily the fastest way to get technical questions answered.

感谢有用的输入人员。
事实上，由于故障是随机和间歇性的，所以不可能在部分中进行捕获。
我所知道的只是初始化数据是不正确的，但它在同一个地方从来没有错，但可能在数据流中的任何地方，或者数据可能适用于8或9个简历，但随后会失败。
事实证明这是/ HOLD线上的一个小故障，这是由于制造中已经替换了不正确的组件。
我能够使用IkaLogic Sc​​anaPLUS跟踪它，因为我可以将其设置为一次捕获10分钟，然后继续重置设备并注意它失败的次数。
然后我可以看看那些时候的数据包捕获，很明显出了什么问题。
实际上我可以踢自己，因为我应该注意到的是数据很好，除了缺少部分。
这显然是/ HOLD被断言的地方，因此数据不同步。
如果我看到它可能给了我一个线索，从哪里开始寻找。



     以下为原文

  Thanks for the useful input guys. As it happens it would not have been possible to do the capture in sections as the glitch was random and intermittent. All I knew was that initialisation data was incorrect but it was never wrong in the same place but could be anywhere in the data stream, or the data could be good for 8 or 9 resumes but then would fail.

It turned out to be a glitch on the /HOLD line that was due to an incorrect component having been substituted in manufacture. I was able to track it down with the IkaLogic ScanaPLUS because I could set it up to capture for 10 minutes at a time and just keep reseting the unit and noting the times that it failed. I could then look at the packet capture at those times and it was obvious what was going wrong.

Actually I could kick myself because what I should have noticed was that the data was fine except that there were sections missing. This was obviously where the /HOLD was being asserted and so the data was out of sync. If I had seen that it might have given me a clue as to where to start looking.