Total Samples Per Channel

[Vkerkez]

Hello,

I was wondering if you can call a function that returns the total number of samples per channel read. I am trying to get a accurate time stamp.

I am using the DAQmx ANSI C developer enviorment. 

According to NI:

Option #1:

Try and do exactly what the driver does.  This will require you to do exactly what you are doing in the posted example.  Call the current system time immediately prior to calling the DAQmx Read and subtract dt * x where x is the number of samples already acquired.  This will require you to know exactly how many samples have been acquired.  This can be found by calling the Total Samples Per Channel Acquired property immediately prior to the DAQmx Read.  This introduces some points of innaccuracy.  For example, you're system time is already innaccurate to some amount.  In addition, it takes some time between calling system time, calling the total samples acquired, and calling the DAQmx read.  If 2 samples are acquired between calling the system time and total samples acquired, you could be off by a few samples.  For slower clock rates, you will have more accuracy.

I am trying to attempet to program this solution, but cant find the total samples per channel acquired property. If anyone can help me out, your help will be very appreciated.

Thank you for your help,

Vladimir 

[John_P1 · Accepted solution]

Hi Vladimir,

Here's the property that you're looking for (from the C Reference Help):

You will be able to get accurate relative timestamps since we know our acquisition is based off of a sample clock with a certain dt.  The initial time value still has to come from the OS.

Best Regards,

John

[Vkerkez]

First off. Thank you so much taking your time to answer my question.

Is dt is equal to 1/sample Clock rate. Is the sample Clock rate our sample gathering rate? I am currently gathering 3000 data points per second.

thanks,

vlad 

[John_P1]

Hi Vlad,

Yup, dt would be equal to 1/Sample Clock Rate.  One thing to consider is that a 3 kHz sample rate will actually be coerced up a bit since our Multifunciton DAQ devices use a Divide Down clock.  

On a device with a 20 MHz timebase (M and E series), 3kHz would be coerced to ~3000.3 Hz (20 MHz / 6666).  Dt in this case would be exactly 0.3333 ms

On a device with a 100 MHz timebase (X series), 3 kHz would be coerced to  ~3000.03 Hz (100 MHz / 33333).  Dt in this case would be exactly 0.33333 ms

This may or may not make a difference for what you are trying to do, but I just wanted to give as much information as possible.

Best Regards,

John

Message Edited by John P on 09-11-2009 03:43 PM

[Vkerkez]

What were doing right now is collecting a gps signal. We find out the start time of the signal and compare our time stamp to it. We want milisecond precision but we do know there are inaccuracies of getting a time stamp from the system. Right now our time stamp falls right into the second of the gps time but its about .042000 of target in seconds.

Is that as good as it will get? Is there a more accurate way on getting time stamps? 

thanks,

vlad 

[John_P1]

Hi Vlad,

How are you acquiring the GPS signal, and which DAQ device are you using?  We have a couple of solutions available for synchronizing to GPS--you might want to take a look at a PXI system that includes a PXI-6682.  I would post any questions about GPS synchronization to the PXI forum as they should be able to help you better than I can.

Best Regards,

John

[Vkerkez]

We are using the gps system just to test our time stamps. We are acctually collecting seismic data for our final project. For testing pourposes we took our seismic code and converted it to voltage. We collect the gps signal, decode it to time and then compare our timestamp. I dont think well have a gps signal down in the mines.

thanks, 

-vlad