Timing jitter with GPIB and Agilent synthesizer

[Francois Esnault]

Hi,

WHAT I NEED TO DO :

I need to change the output frequency of a synthesizer (Agilent N5181A) using its GPIB port and I need to do that every 50ms or even less.

MY PROBLEM :The frequency switching event seems to happen randomly (has a lot of jitter) when I try to switch too frequently (<70ms) and the frequency doesn't have the right value when i need it. 

THE BIG PICTURE :

My experiment has cycle time of 50ms (I d like to go faster that that, maybe down to 30ms) and I run it continuously

It has basically 2 steps. The first one lasts 40ms (that is the step i m trying to shrink) and I don't need the synthesizer signal during it.

The second step is about 10ms and I do need to have the synth. frequency properly set here.

MY CONFIG :

I m using a PXI chassis with couple boards (DIO6535 and DAQ 6281) and a NI USB-DAQ Pad 6015 to control the data acquisition and generation.

I m using also a NI USB GPIB HS controller.

I run Labview 2010 SP1 32 bits with DAQmx 9.3.5 drivers, NI 488.2 2.81 and Agilent drivers suite 15.5

I have a Dell Core 2 duo 2.6GHz with 2GB RAM and running XP SP3.

MY VI :

1- I define all the DAQmx Tasks

2- I enter a while loop in which I have a flat sequence structure with 3 frames

3-1st frame : I set the frequency of the synthesizer with a GPIB "send" command.

2nd frame : I do all the read/write DAQ stuff and process the data

3rd frame : I write into a file

WHAT I DID SO FAR :

I wrote a little test vi with a while loop, a timer and a GPIB send command. This works perfectly, I can switch the frequency every 20ms without any problem and monitored it on a scope. So the problem does not come from the synthesizer itself (the actual switching time is specified <5ms ) and the GPIB setup does not seem to limit the operation in that case. 

My problem arises when this GPIB command is called within my big experiment vi so I guess there is an interference somewhere.

MY QUESTIONS :

Maybe the USB does not handle very well outgoing data with GPIB controller and incoming data from the Daq Pad.

I have no idea how to check when the GPIB command is actually sent to the synthesizer.

I can't find a way to trigger somehow the GPIB or to make sure the command is sent within a given time window. I was hoping that the flat sequence structure would force the GPIB to send the command before all the DAQ step happens or at least that it would do it during the first step of my experiment.

Is the GPIB controlled by Windows so that I would get windows latency depending on computation, graphics and background tasks... ? 

Would going to a PCI-GPIB or PXI-GPIB be better ?

Thanks for your help

cheers

Francois-Xavier

[johnsold]

Francois-Xavier,

While I am not familiar with your equipment, I see some things in your description which might be worth considering.

First, rephrasing some of your points with a different perspective:

BIG PICTURE:

You have a cycle of 30-50 ms and need the sysnthesizer for only 10 ms of that.

VI:

One loop with three frame sequence structure. The third frame has stuff which could extend the timing. Maybe the second as well if the processing time is significant.

QUESTIONS:

Could the USB interface be part of the problem with two different devices connected?

How can I assure that the GPIB trigger occurs at the correct time?

How can I assure that the DAQ stuff occurs at the correct time(s)?

Is Windows part of the problem?

Second, my comments:

What kinds of DAQ stuff are you doing? Analog in? Analog out? Digital in? Digital out?  How much data and how fast?

Writing to file in the third frame of the sequence structure could be a timing disaster.  The loop cannot proceed to the next iteration until everything in the sequence stucture has completed.  File I/O can be delayed, sometimes by substantial amounts.  Put the file write in a parallel loop with much slower timing.  Accumulate the data and write in larger chunks less often.

Can the synthesizer be triggered from an external digital signal? If so, consider triggering it from a digital output that is synchronized with your other activities.

Consider processing the DAQ data in a parallel loop if it does not need to be processed to make the synthesizer frequency decision.

Can the synthesizer be left running and the output signal gated by some external hardware controlled by a digital out signal?

Consider making any analog input task run continuously.  Simply discard any irrelevant data.  This may be quite a bit faster than turning it on and off.

Consider a Producer/Consumer architecture.  This is a good way to implement the parallel file and other operations. It might be worthwhile to put all GPIB communications in its own loop.  DAQ in another loop (or 2 or 3). Use queues to pass data and notifiers for synchronization of the loops.

Make sure that each USB device is on a separate bus if available or on separate hubs if separate buses are not available.  Do not put anything else (especially keyborads or mice) on any bus with a DAQ or GPIB device on it.

Any device connected outside the CPU will require an OS call to operate. So GPIB, DAQ, File I/O, and keyboard/mouse inputs all go through the OS before they get to LV.  PCI/PXI also have the OS between the devices and the application.

Lynn

[Francois Esnault]

Hi Lynn,

Thanks so much for your time and help on that.

i m gonna test some of your suggestions today but before more informations relative to your comments :

My DAQ stuff : 

with DAQ PXI6281 : * Analog input, 2 channels 200 KS/sec each, continuous measurements.

             * Digital output 1 channel 100 KS/sec (I need this guy because it is a 5V signal)

      * Analog output 2 channels 100 KS/sec, regeneration mode

with DIO PXI 6535 : * Digital output 7 lines, 100 KS/sec (only 3.3V output signal), regeneration mode  

with DAQ Pad :       * Analog input, 1 channel 100KS/sec, continuous (I need this guy because I need the full speed of the AI PXI )

     * Analog Output, 1 channel 200S/sec. 

The PXI 6281 Analog Output clock is used as a master clock for the DIO and Daq Pad and acts as a master trigger.

I thinks this all DAQ part works fine. If I don't modulate the synthesizer frequency from a cycle to another, it keeps up with cycle time down to 20ms ans stays nicely in sync.

For the writting file part, it doesn't seem to be an obvious limitation. I tried to run my .vi disabling it and I experienced the same issues with the GPIB. Also as mentionned just before, I can run the vi with 20 cycle time without experiencing problems. However, I totally agree this is something I need to change as you proposed.

 For ther synthesizer itself, I haven't found a way to trigger it externaly while using the GPIB to update the frequency value register. It would probably help debugging but I would still rely on when the GPIB command is sent from ther PC to the synthesizer.

I do need to compute the data to derive the synthesizer frequency value so i m stuck with computation in the main loop.

I m gonna check the multiple loop architecture and the USB buses and stuff (I didn't think of the mouse and keyboards, good point)

Thanks again

FX