Actual sample rate possible

[hugh1409]

I am using a PXI-6723 and PXIe4499 and wanting to use common date rates. i realise the date rate is coerced to the nearest possible supported data rate and this can be found out programmatically but can these be derived from an equation? i have found similar equations for other cards but not these. Apologies if these are obvious but i believe i have looked in the normal places.

[Shuggy1]

I am replying to this post from my primary account as i have released that it would benefit from some additional details. (i am the original author) I have tried setting a data rate of 32768Hz however this particular data rate is not supported by a PXI6723 card and is coerced to 32786.9Hz. A list of the supported data rate would mean that i could give only these rates as a option. The following link...(http://digital.ni.com/public.nsf/allkb/593CC07F76B1405A862570DE005F6836 .. shows how these data rates can be calculated for a different card but the equations are not listed in the user specifications for a 6723. Can the equations be derived from known information, and how would this be done? Many Thanks for you help

[NataliaS]

Hey,

Reading through your post I was wondering if you would be able to provide some additional information.

Few questions that pop into my mind are:

How do you set the data rate?
How do you measure the frequency of 32786.9Hz?

Regards,
Natalia
Applications Engineer

[Shuggy1]

Thank you Natalia, I am setting the data rate using a daqmx timing vi, and can monitor the actual data rate using a channel property node (SampClkRate) output to an indicator. I have included a test Vi that just includes the output side of my program and simulates the acquisition as a waveform. I hope that this clarifies the problem. I understand why there is a difference between the requested and actual rates but can the actual rate be predicted from, for example the clock speed?

[Shuggy1]

Sorry my attachments do not make it through the fire wall.

[DubGuy]

Below the Attachments Shuggy1 asked me to uplaod.

[NataliaS]

Hey,

Looking further into your question I have been able to find a manual which states how to calculate the coerced rate for the NI Dynamic Signal Acquisition modules, including the PXIe 4499

If you check page 24 it talks about Sample rate and Update Rate, Accuracy and Coercsion later on it explains how to calculate Coerced Rate.

http://www.ni.com/pdf/manuals/371235h.pdf

I am still looking into the PXI 6723 module.

Kind Regards,

Natalia

Applications Engineer

[NataliaS]

Hey again,

For the PXI 6723 it seems that the frequency resolution on the analogue output is dependent on Clock Frequency and number of Samples  per Cycle.

Take a look at the "Trouble Shooting, part B" in the Analogue Output Series User Manual:

http://www.ni.com/pdf/manuals/370735e.pdf

Have these informations been helpful?

Kind Regards,

Natalia

Applications Engineer

[Kevin_Price]

It's been a while now since I had to correlate samples between a regular DAQmx card and a DSA card, but I recall several gotchas while doing it.

1. The DSA has a more restrictive set of available sample frequencies.  Life is a bit easier if you let it be the timing master and let the DAQmx card be the timing slave.

2. My DSA card (and thus maybe yours too?) had a non-negotiable but significant delay from the time a signal edge occurred at the physical pin and the time it was stored in the data acq buffer.

3. I think I recall a DSA task property available that could export a signal analagous to a sample clock.  I think it had a different name though, probably to avoid ambiguity due to the way the sigma-delta A-to-D converters work.   The point is, try to use this to drive your DAQmx task with this signal, using it as an external sample clock.  Just be sure to configure the DAQmx task with an approximately correct rate for that external signal.

4. There's still a lurking issue after all this hardware clock synchroniczation.  The delay inherent in the DSA.  At the moment the exported clock-like signal is asserted, both the DSA and the DAQmx tasks will store a sample in their respective data acq buffers.  What's stored in the DAQmx buffer is what was happening at that same moment.  What's in the DSA buffer is what happened a little while ago, due to the signal delay.

   Just be aware so you can figure out how you'd like to compensate.

-Kevin P

[Shuggy1]

Thank you Natalia i think that is exactly what i was asking about however have had to undertake other work and will have to come back to the Labview. Kevin, That is really useful knowledge I'm not at that stage at the moment however your post has given me a number of things to look into and check. I didn't realise that i may have problems above matching the' sample rates'. The delay is not an issue to me but significant variations in the clock speed will increase over time and affect buffering over time. Many Thanks ill post back with a summary for those following this. Cheers