PXI-5671 short delay trigger?

[TimS.]

Hello,

I have the need to develop a very short delay trigger for the PXI-5671 hardware. I have played around with both the software and hardware triggers already and noticed that the delay times are almost too slow for the application my company would wish to use it for. Also, I noticed that the shortest delay is when the device has been moved to the initiated state but is waiting for the trigger before actually generating the signal. I also wish to have information embeded in the trigger that tells the PXI-5671 what frequency to generate a signal at. Unfortunately, I also noticed that once the device is initiated I am unable to modify the center frequency. Waiting for a trigger and then using the NI-RFSG initiate block takes too long for our application.

My question is: Is there a way to decrease the delay times as well as being able to configure the frequency at the same time or will there always be that trade off? The NI-RFSG initiate block just adds too much delay.

As a side note. I am able to use the PXI-5441 by itself because I am looking to do an HF only application, VHF/UHF would be something for the future. Please let me know if that would speed things up as well.

Also, please recommend any AWG hardware that may be faster at this application (i.e. cPCI, cPCIx, PXI, PXI-x, etc.)

Thank You,

Tim Sileo

[TheWoost]

Hi Tim,

I think the best way to try and answer your questions would be to take a look at the NI-RFSG Programming State Model that can be found in the NI RF Signal Generators Help.  Here is a screenshot of the programming state model:

As you can see from the state model, the device must be initiated to go into the generation state.  Once in the generation state, it will either start generating immediately or wait for a trigger to start generating.  The frequency at which the PXI-5671 will generate is set in the configration state and then committed to hardware.  Once the device has entered the generation state you will be unable to modify properties or hardware settings such as generation frequency without aborting the generation session first.

When not using the PXI-5610 upconverter, the PXI-5441 can be programmed with the NI-FGEN driver.  This driver has a very similar programming state model to the NI-RFSG programming state model.  More information about this can be found in the NI Signal Generators Help.

Regards,
Andrew W
National Instruments

Message Edited by TheWoost on 09-13-2007 06:13 PM

[TimS.]

Hi Andrew,

Thank You very much for the information on the programming state model. That will help me out greatly in determining what we can and can't do with the hardware.

Regards,

Tim S.

[TimS.]

Now that I'm a little more familiar with how the niRFSG programming flow works I can ask a little more detailed question about the niRFSG block. I am wondering if it is possible to dig down into the code of the niRFSG block in order to get the hardware into a state which would make initiating generation faster? After using the performance and monitoring tool I noticed that the niRFSG initiate block has taken anywhere from 15ms to 80ms. I understand that script triggering and similar things may be used for around 2-3ms to initiate generation but that won't work for my application since the frequency to generate at is unknown ahead of time. Has anyone used Labview/LabWindows CVI to speed up the initiate generation block?

As another note: I understand that the tuning times for the PXI-5671 (which is the hardware I'm using) are a factor as well. I'm not so conserned with those though because the upconverter will most likely be parked at a specific frequency and the generating frequencies will be within the 20 MHz BW constraints.

[TheWoost]

Hi Tim,

Unfortunately there is no way to dig into the RFSG code for modification because at the lowest level of the VIs they are simply making calls to the driver DLL.  If you are particularly interested in reducing the amount of time for the niRFSG Initiate to take place, you could explicitly transition the device to the committed state using the niRFSG Commit function before calling niRFSG Initiate.  Without this VI, the niRFSG Initiate will first commit the configuration to hardware and then initiate the generation.  I saw from some of your other forum posts that you are using LabVIEW 8.2, so I have attached a VI (modified version of the RFSG Single Tone Generation shipping example) to let you see the execution time differences with and without the niRFSG Commit VI.  On my system the commit process was taking about half of the combined time for commit and initiate.  Let me know if you have any other questions.

Regards,
Andrew W
National Instruments

[TimS.]

Hi Andrew,

The example really helped. After doing some modifications to add better timing mechanisms to my existing vi I was able to get the time to generation down to about 10 ms when not tuning the upconverter and around 40 ms when tuning the upconverter. We were hoping to get it under 10ms always but it looks like that will be the best we can get. I have to re-check the requirements for our project but the 10ms time without tuning may be sufficient.

Thanks for the quick response

-Tim S.