Analog Sample Clock Division

[rtnewsome]

Hi,

I have an analog channel I want to sample, and an external 100kHz clock to use as the sampling clock.  However, I'd like to sample at 20kHz instead of the full 100kHz.  How can I divide down the external 100kHz clock to 20kHz so that it can be used as the analog sampling clock.

Specifically, I'd like to use the counter in "pulse train generation" mode to generate one pulse for every 5 clock cycles of the 100kHz clock (to make a 20kHz clock).  Then, I'd like to make the output of the counter (the 20kHz clock generated from the external 100kHz clock) the sampling clock for the VI that aquires samples from the analog input channel.

How do I do this in LabVIEW?  Any hints?

[Stuart_G]

Try this (you won't be able to use the DAQmx timing VI):

Use the DAQmx timing property node and set the Sample Clock.Timebase.Source to the pin where your 100k signal is at.  Then set the SampleClock.Timebase Divisor to 5.  This should work

StuartG

[Tom_W_[DE]]

Hi All-

Alternatively, you can use the DAQmx Timing VI and NI-DAQmx will calculate the Timebase Divisor for you as long as you first specify the external timebase source and rate correctly.  I have attached a quick example that shows how to set this up to achieve a correct timebase division.

Hopefully this helps-

[Tom_W_[DE]]

Also, here's a LabVIEW 7.1 version of my previous VI just in case-

[rtnewsome]

I have implemented the clock division in the way you suggested, and it seems like it should work.  However, I'm still having problems....

I have attached my VI.  PFI0 is an external 1Hz clock that I want to use for triggering.  PFI1 is the external 100kHz clock that I want divided down to 20kHz to act as the sampling clock.  I am trying to measure ai0 in continuous mode, and write the samples to a binary file.  You can enter the number of seconds you would like to acquire data, and the VI computes the number of times the while loop should execute based on that input, assuming the sampling rate is in fact 20kHz.  If for some reason the sampling rate were much higher, the VI would wind up finishing its acquisition much more quickly.

When I run the VI, it should sample for exactly 10 seconds (or whatever number of seconds I specify in the "Number of Seconds" numeric).  Instead, it seems to finish immediately (as if it were really sampling at an incredibly high rate, like 10GHz or something), and when I read the binary data file it creates, there are no samples.  Moreover, if I set the "rate" input of the Sample Clock VI back to 100,000 (so that the clock divisor should become 1 and the system samples at 100kHz), an error is generated saying that the sampling clock rate is too high (at 100kHz) and that the highest allowable sampling clock rate is only 50kHz.  I know that is not true, because if I take out the DAQmx Timing Property Node VIs, I can get it to run sampling at 100kHz without any problems at all.

The DAQ I am using is the NI PCI-6254.

So, does anyone know why this setup is not actually sampling at 20kHz, finishing all its while loop iterations almost instantaneously?  And why the DAQmx Timing Property Nodes complain about sampling clock rates higher 50kHz when my DAQ card ought to support 1-channel sampling rates up to 1MHz?  I greatly appreciated the responses so far, and would appreciate any more insight anyone else might have.

-- Robert

[Tom_W_[DE]]

Hi Robert-

The reason your acquisition is completing so quickly is that you're not explicitly specifying the number of samples to read with each iteration, so NI-DAQmx just tries to read whatever is buffered.  In the case of your acquisition, it seems you are not buffering data as fast as you're attempting to read, so I would recommend specifying the "Samples to Read" input as the number that you want to pull from the buffer and write to file with each iteration of the loop.

It would be easier to use a finite acquisition since in essence you are really determining the number of points to acquire based on the user input.  I would suggest using the DAQmx Timing VI to specify "Finite Samples" with the number of samples equal to [amount of time to acquire] * [sampling rate].  This way you only need to call the DAQmx Read once and you will pull the entire acquisition from the buffer and write to file all in one step.

Can you please let me know the error number you're seeing and attach a screenshot if possible?  Thanks a lot-

[rtnewsome]

Great...  Wiring 2000 to the "Number of Samples" input of the Analog 1D DBL 1Chan NSamp VI made everything work correctly.

As for your suggestion on switching the acquisition mode to finite from continuous, I wasn't quite sure myself which mode was appropriate for my application.  (If you can't already tell, this is my first experience with interfacing LabVIEW with a DAQ and I am still figuring out how all the DAQmx VIs operate.)

In my application, I will ultimately want to acquire analog inputs from many channels simultaneously at a sampling rate of 20kHz, do some filtering and decimation to 2kHz in software, and then write the output samples to files on my hard drive.  The application will need to take, process, and record data like this continuously for periods on the order of 12 hours.  Certainly, I can't read 12 hours of data into my RAM and then do the processing and recording afterwards, so I need to do the processing and recording on data that has already arrived while new samples are simultaneously being acquired.

I was afraid that if I used the finite acquisition mode, I might miss some samples.  I don't want acquisition of samples to halt when I start processing and recording the samples that have already arrived.  If I use the finite acquisition mode, I fear that this might happen.  I would make a loop that acquires N samples, and then stops acquiring samples until the N samples had been processed and recorded.  I have been told that in continous mode, the acquisition of new samples doesn't stop when the older samples are being processed and recorded.  This is what I want.  Can I make the finite acquisition mode perform in this manner?

The error number of the error I mentioned above was -200332.  Attached is a screenshot of the error message.

Thanks for your advice.

-- Robert

[Tom_W_[DE]]

Hi Robert-

The reason your app is failing with that error is because in order to use a sample clock divisor you actually have to perform a division.

If you want to sample at the full rate of your sample clock input you can simply skip the specification of an external sample timebase and just specify the sample clock source to the DAQmx Timing VI as some PFI line.  If you need to switch back and forth between division and no division, I would just monitor for any changes to the sample clock specification and calculate whether a sample clock division is necessary or not.  If so, you can just destroy the existing task and create a new task that uses the appropriate sample timing definition.

Hopefully this helps-

[SuperSnake428]

I am designing a custom test board for an IC that I designed. Unfortunately, today I realized that I made a mistake and should have divided down the external sampling clock on the test board. I was hoping that this trick would work for me, but unfortunately I get an error when I try this.

Error -200452 occurred at Property Node DAQmx Timing (arg 1) in Acquire - FDM 2 - 2.vi

Possible reason(s):

Measurements: Specified property is not supported by the device or is not applicable to the task.

Property: SampClk.Timebase.Rate

Task Name: _unnamedTask<15>

Error -200452 occurred at Property Node DAQmx Timing (arg 1) in Acquire - FDM 2 - 2.vi
Possible reason(s):
Measurements: Specified property is not supported by the device or is not applicable to the task.
Property: SampClk.Timebase.Rate
Task Name: _unnamedTask<15>

What I have is a 20 MHz external sampling clock (connected to APFI1) that I want to divide by 2 to use as the sampling clock (digital inputs). I am trying to use an NI-6289. Any suggestions would be greatly appreciated.

Thanks,
Drew

[SuperSnake428]

Just a quick update, it doesn't look like I can use a counter because I only need to divide by 2 not 4 (which it seems that the counter option is limited to). I really hope that this is possible!!

Thanks,

Drew