PXI-5660 and Star trigger and t0

[KR4K]

When usinging a triggered PXI-5660 collection, the IQ waveform output of ni5660 Read IQ.vi includes y, dt, and t0. What is the meaning of t0 since the acquisition should have started at precisely the star trigger instance (actually within the propagation distance between the star trigger generator and the 6520, < 1ns).

How accurate is this triggering - 1 ns, 10 ns, 100ns, etc. ?

I noticed that the ni5660 Read IQ.vi does not include the niScope initiate Acquisition.vi. If you place this just prior to the ni5660 Read IQ.vi, does it improve the time sync?

73/gus

[MicrowaveDave]

Hey,

To answer your questions, the timestamps for National Instruments digitizers have been measured to be accurate to within 2ns (absolute time).  In addition, this timestamp will occur when the aquisition begins, after recieving the trigger.  With the PXI Star trigger, the propagation delay can be up to 7ns.  The digtizer boards are able to do this by synchronizing with the system clock at startup.  In addition, there is no need to put an NI-SCOPE Initiate VI at the beginning of the acquisistion. 

Thanks,

David Hall | Applications Engineering | National Instruments

[KR4K]

Thanks.

Given the scenario where we use the Star trigger to start the sample, what does t0 mean in the waveform sample from ni5660 Read IQ.vi?

73/gus

[minh.tran@ni.com]

Good morning 73/gus,

Thanks for contacting National Instruments with your issue, we'll try our best to resolve it for you as quickly and efficiently as possible.

The t0 returns the trigger (start) time of the acquired signal, which is essentially the timestamp of the first acquired signal. 

Best of luck with your project.

Sincerely,

Minh Tran
Applications Engineering
National Instruments

[KR4K]

If it were the trigger start time, it should match the GPS star trigger time exactly (within a couple nanosec). However, it doesn't. t0 appears to be the sample period, not any referenced time. I sample at 2 Msps, and t0 = 5e-7.

Since the Star trigger time is GPS based. Is t0 some offset difference between the Star trigger and the center of the first sample period, time referenced to the system clock, or what?

Why is there a difference between t0 and the Star trigger time which started the capture?

73/gus

[Erick]

Hi Gus,

Let me clarify the triggering functionalitty on the PXI-5660. 

How accurate is this triggering - 1 ns, 10 ns, 100ns, etc. ?

The trigger accuracy on the 5660 is one sample period.  Since the 5660 operates at 64 MS/s then our trigger accuracy will be 15.625ns.  David mentioned a trigger accuracy of 2 ns but this is only with our SMC (synchronization & memory core) devices.  SMC devices include the 5122, 5142, 5124, 5441, 5421, 6552, etc.  These boards have triggering circuitry that is very accurate at calculating the exact trigger timestamp.  The PXI-5620 does not have this circuitry.

Why is there a difference between t0 and the Star trigger time which started the capture?

With the NI-5660 VIs, the t0 that you are seeing is the relativeX.  It's not the absolute timestamp but instead is the relative position of the first sample compared to when the trigger actually occurred.  This t0 value can be negative meaning that you are taking pre-trigger samples.  If the t0 value is positive then the first sample came after the trigger.

There is another element to discuss regarding triggering with the PXI-5660.  The PXI-5600 downconverter has a signal chain propagation delay of 1200ns.  This means that if a digital trigger arrives at the digitizer, the actual data will not start arriving until 1200 ns later because the analog signal has to propagate through the PXI-5600.  The easiest way to work around this is to implement a fetch offset property.  Go into "ni5660 Fetch IQ.vi" and place a niScope Property Node before "niScope Fetch Cluster.vi".  Change the property to fetch offset and indicate the number of samples you'd like the offset to be.  For the 5620 running at 64MS/s you would need the fetch offset to be ~76 samples.

Let us know if you have any further questions.  Best of luck on your application!

Erick

[KR4K]

Thanks. That helps a great deal.

Is the 1200 ns delay fixed and common to all ni5660 acquisitions?

When you use ni5660 Configure for IQ.vi, you set the bandwidth, which causes a corresponding change in the reported sample rate.  For example, 1 MHz BW results in a 2 Msps reported sample rate. 2 MHz BW results in a 2.56 Msps reported sample rate (read via MT Get Attributes.vi or ).

So the actual sample rate would determine the offset to ensure the first sample is really at the proper Star Trigger time. For a 2 Msps (500 ns), for triggering, we would only need either 2 or 3 offset. Is that right?

We would need the same offset on all the remote units that are to trigger at precisely the same time.

Is there any improvement in the offset requirement or stabalization of t0 by using the niScope Initiate Acquisition.vi, by having the digitizer leave the idle state shile waiting for the Star trigger? Perhaps using a lower-level niScope aquire (niScope Read Cluster.vi) would be faster?

73/gus

[Erick]

Hi Gus,

You are correct.  The PXI-5620 has two modes, DDC (digital downconverter) on and DDC off.  The DDC is on when the bandwidth is <1.25MHz.  The DDC is off when the bandwidth is >= 1.25MHz.  When the DDC is off the sampling rate is 64MS/s and this is the number of samples that are acquired.  If you are operating with a bandwidth below 1.25MHz then you will have different DDC rates.  The table attached shows the bandwidths and corresponding DDC rates.  So with the DDC on you will not have to throw as many samples away, everything you said is correct.

Is there any improvement in the offset requirement or stabalization of t0 by using the niScope Initiate Acquisition.vi, by having the digitizer leave the idle state shile waiting for the Star trigger? Perhaps using a lower-level niScope aquire (niScope Read Cluster.vi) would be faster?

The example "ni5660 Trigger IQ.vi" already uses low level niScope calls.  They are contained in the 5660 VIs.  The program calls niScope Initiate Acquisition.vi and niScope Fetch Cluster.vi.  The fetch function will wait for the trigger to arrive and timeout after a specified amount of time if the trigger doesn't arrive.  All the triggering is dependent on hardware so the software calls will not make the triggering faster or more accurate.

Let me know if you have any other questions.

Erick