why is relativeInitalX value not accounting for trigger delay? using NI scope with PXI-5124

[psmorris]

Hi All,

playing with a PXI-5124 digitiser in a PXI1042Q crate with a PXI8110 controller, running labview 2012 (latest updates) with latest NIScope driver.

I've set up a delayed trigger acquisition (by setting the trigger delay to, for example 20us) which works fine (I can tell from the signal I get that the delay control is working correctly), but the data returned in the wfm info cluster (using the 2D I16 version of niScope Fetch) doesn't reflect that delay.

The description of the relativeInitialX indicator within that cluster states "is the time in seconds from the trigger to the first sample in the acquired waveform" but its only ever returning something around 1E-9 independent of trigger delay. Surely the relative initial x should reflect the trigger delay? 

Am I doing something wrong?!

Thanks for your help!

[Nathan-P]

psmorris,

The behavior your experiencing is correct.  the value in relativeInitialX is the time between the first sample fetched and the record's trigger, just like you said, but its not relative to the trigger you set up, its relative to the delayed trigger.

When you specify a trigger delay, your telling the digitizer to delay processing the trigger event for 20uS (in your case), thus the actual trigger the digitizer uses is the time delayed one, and its this time-delayed trigger that relativeInitialX is reporting relative to.

RelativeInitialX will not show the trigger delay time because the "trigger" it is relative to is actually the delayed trigger, not the original trigger.

I hope that helps! 

EDIT:

In the following link, the grey part of the waveform is the record acquired, and the reference trigger in the middle of it is what relativeInitialX will use to reference off of.

http://zone.ni.com/reference/en-XX/help/370592N-01/digitizers/trigger_delay/

[psmorris]

Thanks for the response.

I understand what you're saying - so basically, if I want to know the delay from my trigger to the first sample in the record, I just add my trigger delay value to the relativeInitialX.

Its not the behaviour I'd expect from a benchtop scope (hence my initial confusion and thinking it might not be usual - this is my first foray into scope cards!), and it could pehaps be made more clear in the documentation - even in that page you link to, nowhere does it graphically describe where the relative initialX value actual is. Out of interest, in the example you showed there, would the relative initial X value actualy correspond the 50% point in the record or the first point in the record? The "record trigger" is the middle line right, so you'd expect relative initialX to be -1/2 the record length?

Thanks for clearing this up!

Paul

[Nathan-P · Accepted solution]

So, I've made a screenshot of the image in the "Trigger Delay" topic link I sent you.  

Symbol Meanings:

t0 = time of original trigger

t1 = time of trigger used in the acquired record (t1 = t0 + TriggerDelay)

t2 = time of the first sample in the acquired record.

rx = relativeInitialX = t1 - t2

Response to previous comments

"I understand what you're saying - so basically, if I want to know the delay from my trigger to the first sample in the record, I just add my trigger delay value to the relativeInitialX."

• Close, the delay from the original trigger (t0), to the first sample in the record (t2), would actually be TriggerDelay-relativeInitialX

"...nowhere does it graphically describe where the relative initialX value actual is."

• Right, relativeInitialX isn't a timestamp so it doesn't have a location on the timeline, its the difference between two timestamps (t1 and t2 above), hence the name relativeInitialX.

"The "record trigger" is the middle line right, so you'd expect relative initialX to be -1/2 the record length?"

• Almost correct, because the reference trigger is at the 50% position, relativeInitialX will be the time in seconds of 1/2 the record length. (i.e. if the record was 2sec long, relativeInitialX = 1sec).  RelativeInitialX will always be the time delta between the trigger(t1) and the first sample returned in the record(t2).
• Example using image above: If t0=10sec, Trigger Delay=3sec, SampleRate=1kHz, record size=1000.  This means then that t1=13sec.  Our record is 1sec long (1000 points at 1ms between each = 1sec), so t2=12.5sec.  So far all these times are absolute time, like timestamps.  So relativeInitialX= t1-t2 = 13 - 12.5 = 0.5sec. 
• Just as a side note, the reference position doesn't have to be 50%, you can configure it to be anywhere from 0%-100%.

Record Time Attributes not yet discussed

I don't want to make you more confused, but there is another useful attribute in the waveform info that we haven't discussed yet, and its AbsoluteInitialX.  From the NI-SCOPE help file: "absoluteInitialX is the timestamp in seconds of the first fetched sample..."  Thus, using the image above, absoluteInitialX = t2.

I hope this helps.  If any part is still unclear, let me know.

-Nathan

[psmorris]

That's very helpful, thank you!

For our application I'm interested in the time between the actual trigger event (on the external trigger line) and the signal we then detect. Basically, its an ultrasound application, so there's always some delay whilst the signal (generated at the same time as the external trigger event) propagates through the water before getting to the detector. So we'd always set the reference position as 0 and then use a trigger delay. So long as I have a way to relate the time of the first point in the record to the external trigger event, I'm happy!

Thanks for your help!

Paul

[Nathan-P]

Great I'm glad that helped.  Just a note, if your reference position is zero (0), then relativeInitialX should also always be zero (since the first sample in the record is the same sample that the trigger is at).

Good luck on your application!

[Henrik_Volkers]

---

@Nathan-P wrote:

Great I'm glad that helped.  Just a note, if your reference position is zero (0), then relativeInitialX should also always be zero (since the first sample in the record is the same sample that the trigger is at).

Good luck on your application!

---

I have to question this, because my understanding is, that the relativeInitialX is a time with subsample resolution, if you record multiple channels at different rates, relativeInitialX should indicate that even if the reference position is zero.  

[Nathan-P]

Thanks Henrik_Volkers,

Your right, NI-SCOPE calculates the timestamps from the trigger using TDC counters, which do provide sub-sample accurate timing.  Thus:

@Nathan-P wrote:

Great I'm glad that helped.  Just a note, if your reference position is zero (0), then relativeInitialX should also always be zero

---

is wrong, and instead of being zero, will be extreemly small, and smaller than the period of your sample clock (sub-sample accuracy)

Thanks,

Nathan