PXI

cancel
Showing results for 
Search instead for 
Did you mean: 

Unwanted trigger delay using TClk on PXI-1033 chassis with PXI-5412 and PXI-5122

Hi,

 

I've got a few problems with NI-TClk synchronization of 5412 AWG and 5122 digitizers on PXI-1033 chassis. My goal is to perform the multichannel multi-acquisition task with a tight synchronization between 1 AWG and multiple digitizers.

 

So far, I've been able to achieve that goal utilizing the reference clock synchronization via the PXI reference clock and using the software trigger on AWG and the digital edge trigger on digitizers (see first .vi). The started event or marker event (set to 0 sample) is exported to the RTSI0 line from the AWG and serves as a reference trigger (ref. pos. = 0) for the digitizers. This approach seems to be working very well. The acquired signal precisely corresponds to the signal that was uploaded to the AWG.

 

I've been trying to do the same thing using TClk synchronization, but haven't found the right way yet. My .vi is working, but there's always an unwanted delay in the trigger event. It seems that the digitizers always trigger a bit later than they should. The acquired waveform is then shifted in comparison to the signal, acquired the way I described in the previous paragraph and also to the uploaded waveform (see figure).

 

Any ideas what's the problem? I've already tried to use even the software trigger and set the AWG as TClk master session, but the result was the same.

 

Kind regards,

Jan Hettler 

0 Kudos
Message 1 of 4
(5,724 Views)

Dear Mr. Hettler!

 

There's an example dealing with your particular setup (synchronizing AWG with a HS Digitizer, that is), you can find it here. Could you test your setup using this VI?

 

Also, to correct for propagation delays in slave devices, you can add some delay in the master (the FGEN in our case).

TClk Delay.gif

What was the sample rate in the picture you've attached? Since I'm assuming you're using loopback to test synchronity, there should be some delay between the AWG and digitizer, to account for propagation delay of the DAC + wire + ADC.

 

Best regards:

 

Andrew Valko

NI Hungary

 

Andrew Valko
National Instruments Hungary
0 Kudos
Message 2 of 4
(5,701 Views)

Dear Mr. Valko,

 

I've tried to make the modification you've suggested. However, the difference between TClk and ordinary triggering persists. I ran the NI provided example, I've also added the TClk delay to my code (with the smaller delay - 5412 refuses to use 0.01, the value is out of range) and ran it. The good thing though is, that all these programmes produce the same signal (one group in the fig.)- regardless of TClk delays and other modifications. The bad thing is, that it's still way different from RTSI0 triggering with StartedEvent or MarkerEvent set to 0 (the other group in the fig. ).

 

Attached you can see the comparison for first few samples, done after the measurement using the stored data. Signals were collected at 10 MS/s, 1000 samples, DC coupling, 50 Ohms - direct from AWG to DAQ via 10 cm long cable. I agree, that there is an intrinsic delay caused by circuitry and physics. The difference here is approximately 10 samples (1us) and I'm not sure if it's really caused by this.

 

Any other ideas why are RTSI0 and TClk triggering so different in my application?

 

Kind regards,

Jan Hettler

 

0 Kudos
Message 3 of 4
(5,692 Views)

I am a CVI user so my ability to quickly look through your code is nonexistent.

 

However, TClk and digitizers has (at least in my case) this little disadvantage that the digitizer needs to fill its buffer prior to triggering. In my application, I already use waveform scripting and external triggering anyway and so I use a dummy waveform  which is software triggered to satisfythe buffer requirement. This waveform(all zeros and as short as possible) runs immediately and  a later external trigger to the AWG generates a marker event trigger across the backplane for the digitizer. While still not exactly "simultaneous" as the marker has a finite length, it works very well for our application.

 

The repeatability of such a solution is quite impressive, and in our case the exact accuracy is a second order concern.

 

I should still have a post of this soultion somewhere in the CVI fourm.

 

I hope this helps and good luck.

0 Kudos
Message 4 of 4
(5,667 Views)