LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

issue with PPS signal to trigger AI start

In my PXI (PXIe-8442 controller in PXIe-1092 chassis with Timing and Synchronization upgrade) I have a PXIe-4468 (DSA analog I/O) and a PXI-6683H (Timing module)

I'd like to use the PPS signal to trigger the start of the analog acquisition, I've built the attached VI :

TiTou_0-1728035798292.png

so I expect the `to`indicator (coming from the acquired waveform) to be equal (or at least very close) to the `pps-start`

instead, `t0` is smaller than `pps-start`

 

if I set `don't send PPS`to TRUE, there's no trigger to start the acquisition and as expected I get a timeout after 8 seconds from the ai read VI

 

What am I missing?


We have two ears and one mouth so that we can listen twice as much as we speak.

Epictetus

Antoine Chalons

0 Kudos
Message 1 of 13
(321 Views)

@TiTou wrote:

 

What am I missing?


Not sure I completely understand the issue, but

  1. t0 from DAQmx is a software based timestamp, it will not be accurate unless using a TSN system which is not the case here. (FYI, I started two tasks with a digital trigger and have gotten different t0's, even though the task were synchronized.)
  2. I assume you are using Windows. The reference time from the 6683H can be different from the system time in Windows; I have seen them off by multiple seconds. Are you sure these two times are synced because DAQmx is not getting the time from the 6683H. (I am pretty sure DAQmx just gets the system time from Windows.)
Message 2 of 13
(281 Views)

Curious: how much smaller is 4468 t0 than pps-start?

from the specifications:

dsbNI_0-1728099781264.png


[4] "Digital filter delay is compensated to 0 ns by default and adjustable in software."

Doug
NI Sound and Vibration
0 Kudos
Message 3 of 13
(255 Views)

Besides the filter delay there is the following issue:

Accuracy of the Waveform Timestamp Returned by NI-DAQmx 

 

Use the GPS to trigger at a know time; then after acquisition change the t0 in any files. Not optimal, but unless you have a TSN network and TSN supported cards, not available on PXI, then that is the only option.

Message 4 of 13
(236 Views)

Thank you for your replies, indeed, I was a bit ingenuous getting the t0 from the AI Read.

I've read a lot of doc and got support from NI Tech Support on this.

It turns out it was a bit trickier than I thought.

NI-Sync has to be used to

- use "connect clock terminals.vi" to send the oscillator signal from the PXI-6683H to clockOut,

- connect physically the ClockOut of the PXI-6683H to the backplane of the PXIe

- use "connect clock terminals.vi" to send the PXI_Clock10 to BoardClock,

>> that's to send a GPS disciplined clock to the PXIe-4468

 

Then AI task must use PXIe_Clock100 as a ReferenceClock Source (having this option required to enable advanced option on the daqmx dropdown menu)

 

I'll cleanup the code and post it in case it can help anyone in the future.

 

I have to say I was impressed with how good the tech support from NI was on this issue.

 


We have two ears and one mouth so that we can listen twice as much as we speak.

Epictetus

Antoine Chalons

Message 5 of 13
(210 Views)

@TiTou wrote:

Thank you for your replies, indeed, I was a bit ingenuous getting the t0 from the AI Read.

I've read a lot of doc and got support from NI Tech Support on this.

It turns out it was a bit trickier than I thought.

NI-Sync has to be used to

- use "connect clock terminals.vi" to send the oscillator signal from the PXI-6683H to clockOut,

- connect physically the ClockOut of the PXI-6683H to the backplane of the PXIe

- use "connect clock terminals.vi" to send the PXI_Clock10 to BoardClock,

>> that's to send a GPS disciplined clock to the PXIe-4468

 

Then AI task must use PXIe_Clock100 as a ReferenceClock Source (having this option required to enable advanced option on the daqmx dropdown menu)

 

I'll cleanup the code and post it in case it can help anyone in the future.

 

I have to say I was impressed with how good the tech support from NI was on this issue.

 


I did the same exact thing with NI-Scope. Because NI-Scope doesn't have a logging feature like DAQmx I had to write my own. That allowed me to use GPS time for my t0. You can use NI-Sync to set a time trigger on the backplane; you can then use that trigger as the real t0 of your data, this should give you the option of having not only a GPS conditioned clock, but also an accurate timestamp.

0 Kudos
Message 6 of 13
(200 Views)

Actually my code is only partially working now...

 

Sending the start trigger on a rollover second works when the GPS board (pxi-6683) is synched

 

But I'm currently not able to discipline the onboard clock of the PXIe-4468 to the GPS clock, here's a simplified VI (LV2020) that I made with step by step documented intent.

 

The plan is to connect physically the clock-out of the GPS board to the PXIe backplane and force the DSA board (PXIe-4468) to discipline its onboard clock to the GPS.

Then Generate a pure tone (50Hz) on the ao channel, and I compensate the AO filter delay by adding a phase angle equivalent to he delay (at 50 kHz sample rate the ao filter delay is 0.00335 which correponds to 60.3° of phase angle).
I use a PMU (GPS synchronized as well) to measure the phase angle continuously and I get a steady increase :

TiTou_0-1730393794204.png

This is over 40 minutes


Clearly, the attached VI is not reaching the goal, the PXIe-4468 is not synchronized with the GPS 😞

What have I missed? Is there a better way of doing this?


We have two ears and one mouth so that we can listen twice as much as we speak.

Epictetus

Antoine Chalons

0 Kudos
Message 7 of 13
(129 Views)

Try to explicitly set the reference clock rate after setting the source. For some X-Cards I believe it is 100MHz, for your DSA card it should be 10MHz. See if that helps.

 

mcduff_0-1730399563171.png

Lastly, how are you measuring the phase drift?

 

0 Kudos
Message 8 of 13
(120 Views)

One more thing to try, query the output sample rate after setting it; you may not be at exactly 20kHz like you assume.

0 Kudos
Message 9 of 13
(109 Views)

@mcduff wrote:

One more thing to try, query the output sample rate after setting it; you may not be at exactly 20kHz like you assume.


Can't edit my previous post but 20kHz is allowed with a simulated instrument. However, the DAQ code has some errors in it; there is no AO filter delay, it is a 16 bit output. The Analog Input has a filter delay.

0 Kudos
Message 10 of 13
(97 Views)