Agilent/Keysight LAs: possible to force "start-of-data' to trigger event?

[testerIsTesting]

Hi all! Is it possible to force the "start-of-data" in a capture to coincide with the trigger event, or at least be defined "deterministically" somehow? Irrespective of how I define triggering, my LA starts dumping data (i.e. "beginning-of-data" marker") before the trigger event, at random edges of the sampling clock.

I'm acquiring synchronous data from an ADC (coming with its own clock) that has been "serialized-by-2" on-chip, so I'm setting up the LA to sample the data on both clock edges. However, due to the serialization, it only makes sense to start the acquisition after a rising edge of the clock. However, the LA seems to position the start-of-data randomly, irrespective of trigger definition:

• If I use no trigger condition the LA starts the acquisition randomly on either edge of the clock (bit13), as shown in "Example 1" below
• If I use a simple trigger condition the LA also starts the acquisition randomly on either edge of the clock, as shown in "Example 2" below
• In fact, irrespective of the trigger definition, the LA randomly positions the start-of-data on either edge of the clock, as shown in "Example 3" below
• All of the above happens also irrespective of the definition of the "Trigger Position" (0%, 100%, 50%, etc) in the "Sampling setup" window

In all the above examples, undesired behavior results when the start-of-data corresponds to a falling edge of the clock, as in this case a "half-serialized sample" is grabbed at the beginning of the acquired data. This condition is quite cumbersome and has to be dealt-with in post-processing (half-sample needs to be discarded; LA capture depth needs to be 2x larger than really needed, etc), and I am trying to avoid it altogether.

So...how can I force the start-of-data to either coincide with the trigger, or be deterministically associated with one of the clock edges or levels? 

Thanks in advance for any help!

P.S. Instrument is a Keysight 16861A; sampling setup as shown in last attachment.
 

[MarkL]

I'm not familiar with the 16861A specifically, but on older Agilent LAs the clock input(s) also appear as data bits along with all the other bits, and are therefore available for inclusion in conditionals.

Have you tried adding a trigger condition CLK1==1 (or however you say it in the 16861A)?

Since this would be sampling a signal that's also clocking itself, you may need to adjust the setup/hold time in the Eye Scan to move the sample point to where the clock is still a 1.   (Assuming this is adjustable on the 16861A; it is on other analyzers).

[MarkL]

So, I think you're also saying you don't want any states stored before the first trigger?  It looks like one is sneaking in on your second example.

Again, caveat this is on older equipment, but in conjunction with the previous post, you can specify "Default Storing" to be "Off" at the start of acquisition.  And then only items strictly including and after the trigger are stored (in this case triggering when CLK1==1).

You can also set up conditions on what states are to be stored after trigger. if not everything.  The default is everything.

[gslick]

I don't understand exactly what your requirements are here.

If you need to sample and store a set of data channels on both the rising edge and on the falling edge of a clock signal, but always want the trigger point to be aligned with either the rising edge or the falling edge of the clock signal, one possibility would be to use demultiplex clocking mode.

For example the falling edge of the clock signal could be set as the slave clock and the rising edge of the clock signal could be set as the master clock. The pod could then be configured in demultiplex mode with the set of data channels assigned to both the slave version of the pod and the master version of the pod. Then each stored state would always be aligned to the rising edge of the master clock signal, and the data for each state would contain a sampled snapshot of the data channels taken on the rising edge of the master clock signal together with a sampled snapshot of the data channels taken on the previous falling edge of the slave clock signal.

The main drawback of using demultiplex mode is that you lose one pod of a pod pair, for example the pod1/2 pair becomes pod1 slave clock and pod1 master clock, and pod2 is gone.

[MarkL]

That's a good point that demultiplexing might be the right answer here if the data out is being transferred in two parts (like high then low) and needs to be reconstituted.

testerIsTesting: What ADC are you probing?