Cannot acquire faster than 100kHz on USB-6351 with simultaneous analog and counter inputs (can use only 100kHzTimebase)

[quicksilver94]

Dear National Instruments users,

I am experiencing an issue with the USB-6351 product.

I need to acquire a signal with two simultaneous inputs (Analog and Counter) on a well-defined clock. Unfortunately, the driver seems to be limiting me to the 100kHzTimebase sample clock timing source - I am not able to select the higher-frequency clocks (20MHz or 100MHz for instance), which prevents me from acquiring the signal at more than 100kHz.
I would like to acquire at least at 600kHz, and ideally 1MHz...

I programmed this using the very good nidaqmx Python module that overlays the standard C driver.

Here is what I did (in this order) to acquire at a desired frequency of rate_hz:

1. Create an Analog Input Task (with a single analog voltage channel on "ai0", and with sample clock timing [rate at rate_hz, sample mode FINITE, source 100kHzTimebase], triggered on a digital edge corresponding to the counter input "PFI0")
2. Create a Counter Input Task (with a single edge counter on channel "ctr0", terminal "PFI0", and with sample clock timing [rate at rate_hz, sample mode FINITE, source 100kHzTimebase] triggered on a digital edge corresponding to the counter input "PFI0").
3. Start both tasks
4. Wait for the pulses to be sent to the counter input
5. Once all the data has been acquired, read both tasks
6. Close both tasks

It works perfectly as long as rate_hz < 100kHz. If I try to specify a higher frequency, I get an error indicating that the frequency is too high. If I try to specify a different sample clock timing source (such as 20MHzTimebase or 100MHzTimebase), it doesn't work either.

Any idea how I could increase my acquisition frequency to at least 600kHz or ideally 1MHz ?

Thank you very much for your help 🙂

[Kevin_Price]

I'm a LabVIEW guy so I don't know the precise syntax you'll need for the text API.   But I *can* tell you that there's gonna be a way to do it with the DAQmx driver.

1. When you setup your AI task for finite sampling, be sure to specify the # samples you'll want to collect.  Same for the CTR task.  Otherwise a default value will be used.  (In LabVIEW the default is 1000 samples.)

2. DAQmx has 2 distinct but similar-sounding concepts related to configuring signals for use as sample clocks.   There's a "Sample Clock Source" and a "Sample Clock Timebase Source."   I don't know which one is designated in the function call you posted.

    The "Sample Clock Timebase Source" would be a timing signal *from which* a sample clock can be derived by dividing it down by some integer.  At least in the LabVIEW API, DAQmx will assume it should use one of the internal timebases (100 kHz, 20 MHz, 100 MHz) unless you go out of your way to specify otherwise.

    The "Sample Clock Source" would be a timing signal that the AI subsystem would use *directly* as a sample clock signal.  

3. On most boards over the years, CTR tasks have been very limited in their ability to derive their own sample clocks from the internal timebases.  One would normally need to provide this sample clock another way, often by borrowing the sample clock signal from another task.

4. So here's what you can do.  Configure the AI task for the sample rate (and # samples) you actually want.  Don't specifically designate any of the timebases, just let DAQmx do its default thing.  Keep the triggering setup as is.

5. Configure the CTR task to use a signal like "/Dev1/ai/SampleClock" as its Sample Clock Source.  (Note the leading '/' character.)   Get rid of the trigger config, you don't need it.  Honest.

6. Start the CTR task before starting the AI task, even if only one line of code earlier.

7. Until a trigger signal comes in, the AI task won't start its sample clock.  Since both tasks depend on that same sample clock, both are waiting.  But as soon as the trigger arrives, both tasks are ready for the sample clock signal that the AI subsystem derives.

-Kevin P

[quicksilver94]

Hi Kevin,

Thanks for this very detailed answer. I tried, and it seems to be working.

I was able to run acquisitions at 500kHz, which is a big improvement.

Thank you !