From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Is it possible to get number of samples much larger than buffer size in Finite mode?

Solved!
Go to solution

Hi All,

 

Thank you for any comments in advance. 

I have a NI 9775 to collect 4-channel analog signals from a scanning microscopy detector. Basically I want the sampling rate as high as possible so that there are more samples to average during the dwell time. However under continuous mode the maximum is 4MS/s, so I'm thinking of taking advantage of the finite mode which can be up to 20MS/s. To get a sequence of valid data, I need to continuously read the data until, e.g. two pulses are collected in the sync channel. But the samples per channel can only be set at most ~2.8M due to buffer size, which may not be enough to get the two pulses. Then the question is is it possible to, for example, store  20M or 40M samples first and then transfer the data 2M per time in finite mode?  I only find a solution in this page (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PA1PSAW&l=en-US) using DAQmx control task (solution 3), but I think it still reads one time for one acquisition.

 

Best,

Yu

0 Kudos
Message 1 of 3
(1,996 Views)
Solution
Accepted by Qincaimao

In short, No.

 

To get high sample rates, samples are collected in onboard memory before they can be transferred to a host PC.  During transfer, you can't also be doing high-speed sampling.   So you're going to be unavoidably limited by the onboard buffer size, stated as 128 Mbits (see pg 13).  Note: that's bits, not bytes!

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 3
(1,897 Views)

Dear Kevin,

 

Thank you so much for your very distinct explanation, which saves me much time.  It turns out that we don't have to push for very short dwell time (like below 1 us), so the current DAQ is probably ok. 

 

Best,

Yu

0 Kudos
Message 3 of 3
(1,879 Views)