daq timing - how to calculate the analog output rate

[Dekay]

I would like to calculate an acceptable analog output rate, one that is supported by the hardware (PCIe6353), without the rate being changed by the DAQmx Timing (sample clock) VI. The end goal is to have an analog ouput rate that is an integer multiple of the analog input rate for improved accuracy, since the sinewave AO is going to op-amps, which have some ringing when AO updates occur.

According to KnowledgeBase 27R8Q3YF: How Is the Actual Scan Rate Determined When I Specify the Scan Rate for My D..., the rate is revised as necessary by calculating board clock/requested rate, divide the result rounded down and up into the board clock, and use the one that is closest to the requested rate.

If 'Onboard Clock' is selected, what is the resulting 'board clock'.  DAQmx sample clock timebase Timing node - SampClk.Timebase.Rate says 100MS/s. However, for a resulting update rate of 2.38095MS/s, the timebase divisor timing node - 'SampClk.TimebaseDiv' gives a value of 42. 42x2.38095M=99,999,990, where it should be 100MS/s.

How do you calculate an acceptable analog output rate that is supported by the hardware? I have other boards, also, so a general method would be appreciated.

[johnsold]

The sample clocks are derived by dividing the timebase clock by some integer value, so the set of possible frequenices is finite. 

If you calculate the nominal frequency (1E8/42) and display the full precision the result is 2380952.38095238106.  Multiplying that by 42 gives 1E8 to 18 significant figures.

The timebase accuracy for the 6353 device is specified as +/-50 ppm. That gives an output frequency range of 2380833 to 2381071 Hz for a divider of 42. So you will not know the actual frequency within ~240 Hz unless you have a very accurate counter.

------------

How are you defining "acceptable rate?" 

How are you deterimining the analog input rate? The analog input and analog output clocks are derived from the same 100 MHz oscillator if they are on the same board. So the sample rates will be integer multiples if the divisors are integer multiples.  You know the nominal timebase frequency so you can calculate nominal sample rates which result in integer divisors.  If you need frequencies which cannot be obtained this way, then you need a different timebase frequency.

What does the sample rate have to do with ringing on the AO? Are you seeing ringing on a sample to sample basis or only at the end of the buffer? Can you post a VI which shows what you are seeing? How are you measuring the ringing?

Lynn

[Dekay]

The calculations are included in the attached VI. The confusion stems from the fact that, even after calculating what the correct AO rate should be, and wiring that to the AO Timing (Sample Clock), a check of the update rate is different.

Thanks for the help. Let me know if you find something wrong with the calculations.

[Dekay]

Also, I double checked the timebase, and it is correct. The rounding error was the problem. Good call. But still, there's a difference between the input and output of the AO rate. The value that comes back from the 'SampClk.Rate' is shown on the front panel under the calculated value.

[Dekay]

An 'acceptable rate' would be one that is not changed by the DAQmx timing VI, one that is already an integer division of the timebase going into the timing VI.

The ringing doesn't have much to do with the post, it was only the motivation for trying to get the AO rate as integer multiples of AI rate. The slew rate of the AO when updating is fast enough to cause a slight overshoot in the output of the op-amp its wired to. If there is a fixed time interval between AO updates and AI sampling, a fixed delay could be used during the settling of the op-amps (DAQmx Timing - DelayFromSampClk.Delay) to avoid the overshoot, hopefully.

[johnsold · Accepted solution]

I have not worked through all the details yet but noticed a few things which may be relevant.

Req AI Rate is not an integer divide from 1E8. It is used to determine the AO rate.

There is no check to verify that AO Rate is an integer divide.

It looks like you have the right idea but the implementation is not quite there yet.

Lynn

[Dekay]

After going through it a few times, the problem was a round down after dividing the AO max rate by the AI rate. The method seems like it will work in general if the max rate for AI and AO are both integer divisors of the timebase, which should be the case.

Thanks for the assist.