PXI

cancel
Showing results for 
Search instead for 
Did you mean: 

Trigger 5154 Scope Card with RTSI 0

I tried out the PFI0 Trigger, the Jitter remains exactly the same as using RTSI0.  I swapped the cards over, then edited the FPGA code to write to PXI_Star, and left to compile.  Will continue tomorrow.

0 Kudos
Message 11 of 22
(2,071 Views)

Hi,

 

The 7842R card is already located in Slot2, the 5154 in Slot3.  I edited the FPGA code to write Trigger to PXI_Star.  I edited the 5154 code to make the Trigger Source PXI Star Trigger.

 

When I run the code it times out, i.e. no Trigger received at the 5154.

 

I've looked the shipped examples for FPGA, cannot find any reference to PXI_Star Triggering.  I notice in some documentation and error messages reference to PXI_Star<n>.  I've looked at the Add FPGA I/O menus for the 7842R for mention of PXI_Star<n>, there are no options to specify any particular lines, only the option for PXI_Star that I've already added.  I'm assuming the term Star implies a Star config emanating from Slot2, so if a Trigger source in Slot2 writes to PXI_Star, the trigger appears at all slots.

 

0 Kudos
Message 12 of 22
(2,063 Views)

Had another look this morning, I'm still unclear why the PXI_Star Trigger does not reach the 5154.  Coding method used is the same as used for RTSI0 Trigger, attached.

 

7842R_write_pxi_star.jpg

0 Kudos
Message 13 of 22
(2,054 Views)

Please keep this service request open, I'm still in need of a solution.

0 Kudos
Message 14 of 22
(2,019 Views)

Hello bmann2000,

 

Thank you for your patience with this post.  I am currently working with my colleagues in the US to discover the underlying functionality of the Signal Routing Matrix when working with the PXI triggers.  I do not have a conclusive answer as to why jitter is being seen, or how to overcome it to just a stable time delay.  I will keep you informed of my progress with this issue.

 

My colleagues in the US appear to be delayed due to NI Week in Austin, however, they are also aware of the urgency of the issue.

 

Regards, 

George T.
Senior Applications Engineer
National Instruments UK and Ireland
0 Kudos
Message 15 of 22
(2,005 Views)

Hello bmann2000,

 

Please see the screenshot, found from the NI Digitizers Help at the following link:

http://zone.ni.com/reference/en-XX/help/370592P-01/digitizers/5122_analog_trigger_paths/

 

NI 5114512251245142 Analog Trigger Paths - NI High-Speed Digitizers Help - Nati_2011-08-08_11-34-26.png

 

I have highlighted the sentence that gives additional information regarding the jitter.   The EXT Trig line is an Analog Interface which directly accepts the signal.  Filters are in place to reject jitter.  The digital triggers going through the Signal Routing Matrix are being digitized.  Therefore, I believe that several samples of the digital signal must be taken to avoid 'false' triggering.  This could be causing the jitter.

 

My US colleague has informed me that the digital trigger lines have a specification for PXI_Trig trigger delay and holdoff, however, they do not have a written specification for the actual jitter, such as the one seen for the Analog EXT Trig.  Furthermore, we have not found any features of the NI-Scope driver that can change the operation of the Signal Routing Matrix.

 

Achieving triggering with the lack of jitter will be possible by using the EXT Trig line.  Please let me know if there are any additional questions.

 

Regards, 

George T.
Senior Applications Engineer
National Instruments UK and Ireland
0 Kudos
Message 16 of 22
(1,988 Views)

Would I be correct to summarise that when using the PXI digital trigger lines, the trigger signal always reaches the PXI card at the exact same instant, as the length of copper between the trigger source and the 5154 is always the same.  However, the 5154 card looks at n previous samples to determine if a trigger has occurred, and this sampling will not always see a high signal for enough n samples to recognise the trigger, and as such it's a bit random as to when the trigger occurs.  Sometimes 1 sample high, other times 7 samples high, or maybe n of 10 samples or whatever the averaging window or algorithm is.

 

Can you please query what the algorithm implemented is ?  this may provide clues to finding a better implementation.

 

Would this problem be present for any PXI_Star or RTSI digital trigger on any NI PXI card ?

0 Kudos
Message 17 of 22
(1,985 Views)

Hello bmann2000,

 

The research thus far is pointing towards the R-Series card is generating the trigger pulse at a fixed rate without adding additional trigger.  Similarly, the distance the signal must travel across the Star Trigger line will be at the same velocity.  The PXI-5154 Signal Routing Matrix is checking for the signal on the line, however, it is most likely the card introducing the jitter. 

 

The Signal Routing Matrix references a clock in the PXI for the rate at which it checks the Star Trigger/PXI_Trig lines.  According to graphics posted earlier, I believe this reference clock is a 10MHz source.  I am investigating whether the PXI-1031 has a specification on the clock, in terms of stability.  If this line is causing the jitter, we can try and reference the  PXI backplane trigger lines against another, more stable source.

 

In the office, I am also running test to verify that the R-Series card is putting signals on the PXI backplane without jitter using additional instrumentation. 

 

Is the PXI-1031 a chassing for development testing only, and not deployment?

 

Regards, 

George T.
Senior Applications Engineer
National Instruments UK and Ireland
0 Kudos
Message 18 of 22
(1,916 Views)

Hi,

 

Yes, the plan is to deploy the PXI-1031DC, hence the DC option.  Would I be correct to assume the 1031DC does not have an external Clk-in input as an alternative to the 10MHz System Reference Clock.  Is the source of the problem the 10MHz driving the digital triggers versus the 1GHz digitizer sampling rate ?

0 Kudos
Message 19 of 22
(1,905 Views)

Hi,

 

A little off topic, but do you know the data transfer rate I should expect from the 5154?  The attached code achieves around 40MB/s before an overwrite error occurs.  I was expecting significantly higher data throughput.  Can you please confirm if the attached code is correct to achieve the maximum data throughput.  I'm aiming for highest possible record length for rep-rates 10kHz, 20kHz, 30kHz etc.....  The attached works for 2channels, 20kHz rep rate, record length 1000, but falls over at higher rep-rates or higher record lengths .

0 Kudos
Message 20 of 22
(1,898 Views)