Which decimated sample is returned in a record on PXI-5122?

[menchar]

If I am decimating the PXI-5122 sample clock by a factor of 20, which of the first 20 original (undecimated) samples is sent to the record as the first sample?

I am using 0% pre-trigger (i.e. 100% post-trigger) and an external sample clock.

What I really want to know is, if I use a digital trigger to the PXI-5122, what is the length of time from trigger until first recorded sample?

Is there a spec for the 5122 that covers this? Not sure what it would be called - trigger delay, maybe? I partially understand trigger holdoff and it would seem that trigger holdoff is not the same issue.

[Erick]

Hi,

This is a great question. There is not a spec for the length of time from the trigger until the first sample is recorded because the digitizer hardware and software compensate for it. Let me try to explain. When a digitizer is initiated it immediately starts acquiring samples into its buffer and keeps overwriting that buffer with data, waiting for the trigger to occur. Once the trigger occurs then it is timestamped and since we know the propagation delay of the trigger through the 5122 the software is able to fetch a few of the samples that were acquired before the trigger. In other words, there IS a delay between the trigger and when the board recognizes it, but since we have pretrigger samples we are able to compensate and fill the trigger delay void. This allows our NI 5122 digitizer to virtually acquire data exactly when the trigger occurs, with sub-nanosecond resolution. This is part of the Synchronization and Memory Core (SMC) technology and more information can be found here:

http://zone.ni.com/devzone/conceptd.nsf/webmain/63ca1e64da2aaa3486256de90003f124#5

Hope this helps!

Erick D
NI Applications Engineer

[menchar]

Hi Erik -

Thanks for the info, though I'm still a bit confused.

Are you saying that for an external sample clock, that the time of the first sample after trigger has less uncertainty than one sample clock period? If the trigger is asynchronous to the sample clock, I fail to see how this could be, even given the fact of constant sampling that preceeds the trigger.

What is the 5122 decimation algorithm, exactly? If the 5122 is decimating by, say, 20, which samples taken by the ADC (at the sample clock rate) are provided in the record? The 1st, 21st, 41st, etc.?

Bob

[Josh H]

Hello,

As Erick pointed out, the digitizer is always sampling once it has started. You are using the digital reference trigger to mark the beginning of sampling that you care about. Since the digital reference trigger can come in at any point in time, the trigger position can be anywhere in between decimated samples.

However, the digitizer does return this information to you in the form of the relative timestamp in the waveform information structure (or cluster in LabVIEW). The relative timestamp is commonly referred to as relativeInitialX.

Typically, the relative timestamp contains information about where the first sample in the buffer fetched occurred in time relative to the reference trigger. So, if we were to represent stored samples as UPPER case and other samples as lower case:

a b c D e f g H i j k L m n o P

Assume a sample rate of 25MHz derived from decimating a 100MHz sampling stream by 4. Also assume the trigger came in at 'g', and you started fetching from 'D.' The relativeInitialX in this scenario would be -30ns (100MHz clock gives a sample period of 10ns). This gives you the sub-decimated sample position of the data (which is the information you need) relative to the reference trigger. It will vary record to record due to the reference trigger coming in asynchronous to the decimation pattern, but at least you know where the sample is (with a precision that is bound by the actual sample rate).

The decimation pattern only resets at Start. So if you provide a digital start trigger, then the first sample acquired after the digitizer recognizes the start trigger should be the first sample stored, the second sample acquired would be the first one dropped by decimation.

The attached example illustrates the information above and may help to better understand the concept.
Thanks,
Josh

[menchar]

Josh -

Thanks for your info on this.

I thought that the relative timestamp was available only if the Time to Digital Converter (TDC) is enabled. With an external sample clock, the TDC is disabled. But you are saying that relative timestamps are still available?

Bob

[Josh H]

Bob,

You are correct - relative timestamps are still available when the TDC is disabled. The only difference is that they won't have subsample accuracy (100ps for the 5122) like they do when the TDC is enabled.

-Josh

[menchar]

Josh -

Thanks again for the info, I understand the relative timestamp issue now. With an external clock, the resolution of the relative timestamp value is one (undecimated) sample clock period. The time from trigger to first sample can vary by up to the decimated sample period unless the external clock and trigger are somehow synchronized external to the 5122.

I am a bit uncertain yet about the decimation pattern. You said the decimation pattern only resets at "start". And you mention a "digital start trigger". I also noticed in the 5122 spec that there are the concepts of a "Start trigger - acquisition arm", an "Arm reference" and an "Advance trigger". Where are these defined / described? The spec itself isn't very helpful. I'll go through the High Speed Digitizers help file and see if I can find anything there.

Thanks again for the info, Josh, and your patience.

Bob Hayes

[Josh H]

Bob,

If you open the High-Speed Digitizers Help and go to Programming>>NI-SCOPE VI Reference Help>>Properties>>Synchronization, you will find a property called "Acquisition Arm Source (Start Trigger Source)". This is the property you will need to set with a trigger line (RTSI 0, PFI 0, etc.) specified as the source of the start trigger. By default this property is set to immediate, but can be configured to be a digital trigger. Once the digitizer receives this trigger, it begins acquiring pretrigger samples and the very first sample it acquires is the first sample in both decimated and non-decimated acquisitions.

Thanks,
Josh

[Red-Eye]

Hi Erick

I think I understand the concept of decimation. How is the answer to the question "which sample is returned?" when your are using Signal Express? It seems to me from the way the measurements on my PXI-5122 look like that after the triggering occurs (e.g. rising edge) it is not deterministic which sample is being taken (jitter). It wouldn't really matter which sample following the trigger event is taken first, if it  were always be the same one. In other words the delay from trigger event to first sample is at random.

My application: I am controlling an analog multiplexer with the PXI-6541. The beginning of the cycle is the trigger signal and I should acquire the (analog) output of the multiplexer right before it switches to next position to give enough settling time. Both devices use the PXI-10 internal clock and the sampling rate for the 5122 is identical to the multiplexer rate. I cannot use a higher rate and record the multiplexer control signal on the 2nd channel in order to "fish out" the right sample, because I need the second channel to record another signal.

Is purchasing LabView the only way out?

Thanks

Hans

[Berto]

Hi Hans,

First off, if you could explain your application in further detail, it could help.  I'd like to know what kind of triggering you're doing here, and if you're acquiring a record for every channel of the multiplexer.

All of the triggers in SignalExpress are reference triggers - so Josh H's post on 06-23-2005 applies here.  The first data point on the decimated clock is the one that will be stored.   This also applies to acquisition with pre-triggering.  So it won't necessarily be the first sample seen - just the first one that lines up with decimated clock.

However, in SignalExpress you will not have access to relativeInitialX as explained in Josh H's post above, so you won't know exactly where the position of the first record is at.

mike