Synchronizing a 6289 with a 4461

[Rolfe]

I'm trying to output synchronized signals on a 6289 (analog and digital outputs) and a 4461 (only analog outputs) on a PXI chassis (a PXI-1031), but I've been having quite a bit of trouble getting the two devices to synchronize. The 4461 documentation indicates that this device can synchronize to a 10 MHz reference clock:

NI PXI-446X devices employ onboard PLL circuitry. The PLL circuitry locks the onboard 100 MHz voltage-controlled crystal oscillator (VCXO) to the PXI 10 MHz reference clock signal, PXI_CLK10. The VCXO output provides the source for the DDS chip, which generates the sample clock timebase. In this way the NI PXI-446X devices lock the sample clock timebase to PXI_CLK10.

However, I've been unable to access this reference clock directly; I can neither read from it nor write to it. Does this phase-locking occur automatically? If I route PXI_CLK10 to the reference clock input of the 6289, will the two cards be synchronized?

Since I haven't been able to assess whether using the PXI backplane's 10 MHz clock as the 6289's reference clock will synchronize the two cards, I've tried a number of other techniques without much success. The 6289 has an accessible sample clock timebase of 20MHz, while the 4461 has a sample clock timebase of 26.2144 MHz, so these seem to be imcompatible, even if a divisor is used. Additionally, the 6289 does not seem to accept Synchronization Pulses, so even if I could share the timebase (as one would do to synchronize multiple 4472s), the sample clocks on the two cards would be out of phase. If I try to share the Sample Clock directly, I find that the 4461 can only use its onboard clock for the Sample Clock, although I can export the 4461's sample clock to the 6289.

Is there any better way to synchronize these two cards? Thanks.

Jason Rolfe

[Jack_A.]

What updates do you want to use for the analog outputs of the M-Series and 4461? Do you want to have the same update rate or different ones?

Something that you will want to keep in mind is that there is a group delay on the output of the 4461. This means that there will be X number of old samples output before the new samples are available. Check out the specifications sheet for the 4461 to see what group delay value you'll see.

-Jack

[jbonk]

Here is the link to the digital filter delay:

http://digital.ni.com/public.nsf/allkb/F989B25FF6CA55C386256CD20056E27D

We had a few issues trying to sync our 4472 cards with a 4461 because of this.

Please update on any success you have with this. We are now in the process of syncing our 4461 and 9 - 4472's with the 6289 we just purchased.

[Rolfe]

Jack -

Ideally, the 6289 (M-series) and the 4461 would have the same sample rate, although it wouldn't be a huge problem if the two cards ran at different rates, so long as the underlying timebases were synchronized. I was planning to use the analog output sample clock of the 6289 to drive the digital output stream on the 6289 (since there is not a separate digital output sample clock), so there is no reason that analog and digital output on the 6289 can't share the same sample rate.

While the delay on the output will be relevant later down the line, my present difficulty is more fundamental than that: I need to synchronize the sample clocks of my two devices so that they do not drift relative to each other. I can correct for a constant output delay by offseting the signals from the two devices in software, but those tricks won't do any good if the hardware is unsynchronized to begin with. How would your recommend performing this clock synchronization?

[Rolfe]

Actually, on the topic of delays introduced by anti-aliasing filters, I don't see any information about filter delays on the 6289's spec sheet. I presume that the M-series cards use some sort of low-pass filter on the analog inputs/outputs. Is this documented anywhere? Thanks.

[reddog]

Rolfe,

The 6289 doesn't have any filters on the Analog Output, so the only filter delays you will have to worry about are on the 4461.

To synchronize the two devices, you have several options. I'll ignore the filter delay on the 4461 for now and come back to it later. First, yes you can use CLK 10 to synchronize both devices. To do this, set the reference clock source to CLK 10 on each device by using the timing property node. For this to work, you will have to have NI-DAQ 7.4 installed since CLK 10 synchronization support for the 4461 was added in this version of the driver. In addition to locking to CLK 10, you will also have to share a start trigger between the two devices. Since there is no trigger support for digital output on the 6289, you will have to use the 6289's ao/sampleClock as the do/sampleClock and start the digital task before the AO task. This solution is nice in that you can output at different rates on the two devices and still maintain phase relationship throughout time.

A second option to CLK 10, is to use the sample clock from the 4461 as the sample clock for the 6289. When using this scheme, you will need to start the digital output and AO task on the 6289 before starting the task on the 4461. This approach is a little more straight forward, but has the disadvantage that it forces all tasks to run at the same sample rate.

Now, we need to address the filter delay on the 4461. So far, the synchronization described above ensures the clocks are synchronized, but it doesn't account for the digital filter delay of the 4461. Depending on the sample rate of the 4461, this filter delay can be 36.6, 36.8, 37.4, 38.5, 40.8, 43.2, 48.0, or 32.0 samples (see the NI Dynamic Signal Acquisition Help for more detailed information). If you are running at a sample rate that doesn't have a fractional sample delay (or you don't care about the fractional delay if it's close enough for you), you have a couple of options. First, you can account for the delay in software by generating waveforms in the software buffers that are already offset by the appropriate sample delay. If you want a hardware driven solution, you can use a start trigger for the AO task on the 6289 and specify a delay from the start trigger of the appropriate number of samples. This can be done through properties under the trigger property node. Using the ao/sampleClock on the 6289 as the sample clock for the digital task will then delay the digital task as well.

If you want to get rid of the fractional delay, you'll have to use the CLK 10 synchronization approach as well as a counter to offset the start of the generations on the 6289 by the appropriate amount. To do this, you'll have to create a counter pulse train task that uses a start trigger. The frequency of the pulse train should match the frequency of the AO sample clock on the 4461. To correct for the filter delay of the 4461, you'll have to calculate the length of time of the filter delay and specify this value as the initial delay for the counter pulse train. The output of the counter is then used to clock both AO and digital tasks on the 6289. The start trigger for the counter task will come from the 4461. So the sequence of events is as follows: 1.) Start the counter, digital, and AO tasks on the 6289, 2.) Start the AO task on the 4461, 3.) The start trigger from the 4461 gets routed to the counter on the 6289, 4.) The counter waits for the initial delay to pass before outputting the pulse train, 5.) The counter starts outputting a pulse train of the same frequency as the sample clock on the 4461 for use by the AO and digital tasks, 6.) The signals on the I/O connector from all three tasks are now synchronized.

Let me know which approach you're leaning towards and I can futher clarify some things if you still have questions. By the way, what sort of application are you developing? I don't typically see this mixture of devices and I/O types.

[Rolfe]

Best advice ever! I had been using NI-DAQmx 7.3, which is why the 4461 refused to recognize the CLK 10 line; I upgraded from NI-DAQmx 7.3 to NI-DAQmx 7.4 and suddenly the PXI_CLK10 line can be fed into the reference clock entry on the timing properties node of the 4461. Everything synchronizes beautifully!

In answer to your question, my lab is conducting behavioral experiments with rats. The tracks on which the rats run contain a bunch of digital I/O devices and speakers. We're using a 6509 to control the most of the digital devices and the 6289 to control timing-sensitive digital devices and play human-audible tones on the speakers. Rats, however, can hear extremely high frequencies, so we're using the 4461 to record their vocalizations and play recorded vocalizations.

Thanks again for the help!

[Rolfe]

A few notes for anyone having similar difficulties:

1) You can actually specify arbitrarily precise delays (up to the precision of the sample clock timebase, I think) using the trigger property node (option Start.Delay and Start.DelayUnits) I don't see any advantage to using the counter to generate the sample clock, but perhaps I'm missing a subtlety here.

2) If you stop a task and then restart it, the 4461 does not seem to clear its output buffer unless you first induce it to enter the Unreserved state. That is, if you try to stop and restart both tasks (rather than erasing and recreating them), the two devices will be synchronized (they will start at the same time if you trigger properly), but the 4461 will be out of phase (it will start in the wrong point of the waveform) unless you manually Unreserve it before restarting.

[reddog]

You're right, there is little benefit to using a counter over the start trigger delay to delay the sample clock if you're using the onboard AO sample clock. The only difference is that counters on an M Series board have 12.5 ns of resolution (80 MHz Timebase) and the trigger delay circuit only has 50 ns of resolution (20 MHz Timebase). Also, if you are using an external AO sample clock, you can't specify a trigger delay since your bypassing the onboard clock circuitry.

The second problem of seeing phase mismatches when restarting the 4461 output seems a little odd. Have you been able to determine if the 4461 starts generating at the wrong point in the waveform (e.g. not the beginning of the buffer)? Or is the 6289 starting at the wrong point in the buffer or losing its start delay information? If I have some time, I'll try to test this out and let you know what I find.