Number of samples is much larger than onboard buffer size

[weszh15]

Hi all,

I need to acquire at least 1 million samples at 2 MHz sampling rate through a digital input port. But the onboard buffer size of my device is only 2047 samples. How can I realize it?

Thanks,

Wesz

[Kevin_Price]

Good news!  The DAQmx driver will be doing most of the dirty work for you in the background.   

When you configure a hw-timed task, a data buffer is created in application RAM.  The driver handles the work of moving data from the board to RAM.  On a desktop PC bus like PCIe, the board gets DMA access to your application RAM in order to deliver data at very high sustained rates (100's of MB/sec or more).  

You just need a board that supports hw-timed DIO and a form of connectivity with enough bandwidth.  The PCIe bus can do it.  I'm less sure about USB.

-Kevin P

[weszh15]

Hi Kevin,

Thanks for your information. I am using NI USB 6221 BNC (datasheet attached) board which supports hardware-timed task. However, I am not sure how fast the data would be moved from the board to PC. If it is slower than the sampling rate, will I lose samples? Also, could you give more explanation about connectivity with enough bandwidth? 

Thanks,

Wesz

[Kevin_Price]

I'm afraid my initial declaration of good news was premature and partially mistaken. 

Your spec sheet states that your USB board only supports up to 1 MHz digital sampling and that it's "system dependent."   The USB bus is a convenient but lower-performing method of connectivity.   You won't be able to sample at 2 MHz with the board you have and even 1 MHz isn't assured.   The hardware will be capable of 1 MHz, the bus may not be.

...time passes.  After checking spec sheets on some other desktop plugin boards I've used (PCI-6229, PCIe-6341, etc.), it looks like 1 MHz sampling for DIO is a very common spec.  I coulda sworn it was 10 MHz.   Hmmm... more time passes...  I've found a few references on ni.com where M-series or X-series as a whole were stated to support *up to* 10 MHz.  I must have thought that meant that the full 10 MHz (or less) was supported on the whole family; in reality it just means that some *subset* of higher-spec'ed boards support that higher speed.

 How many bits are you dealing with and what are you trying to measure & characterize?  Some of the kinds of things people attempt to measure with DI can alternatively be measured with counters.  It's possible your best path forward is with counters.

-Kevin P

[weszh15]

Hi Kevin, 

Appreciate your help. The digital signal I am trying to capture is only 1-bit wide, I need to acquire 1 million samples (i.e., 1 million bits) at 2 MHz sampling rate then use those samples to plot the power spectrum of the digital signal. I was using an external clock as the clock source of the DAQmx Timing vi to synchronize the acquisition with the device generating the digital signal. 

Best,

Wesz

[Kevin_Price]

This sounds like an excellent candidate for a counter task plus some post-processing.

Configure for buffered semi-period measurement using your "1-bit" signal as the signal to measure.  Specify a minimum of about 0.1 microsec and a max of about 100 millisec.  This will likely cause the board to do its measurements using the internal 80 MHz timebase.  (This can also be configured explicitly with a little more work.)

The data you get back will be a series of semiperiod intervals, i.e., an alternating series of high time, low time, high time, low time, etc.  (You can also explicitly configure a starting polarity to specify which comes first.)

A cumulative sum of these intervals will effectively tag each edge with a timestamp that has 12.5 nanosec resolution, far more timing precision than you could get with a DIO task.  From these edge timestamps, you can reconstruct what the DI array *would* have been in case that's useful for some pre-existing post-processing routines.

Gotchas: the very first value in the data array will be pretty meaningless.  It marks the time from when you happened to start the task until the first active edge came in.  It almost always represents an unknown fraction of an interval and should be ignored.  (The newer X-series boards no longer return this first value, but that actually creates different problems that are less recoverable.)

-Kevin P

[weszh15]

Hi Kevin,

If I am understanding it correctly, your method is equivalent to sample my digital signal at the rate of 80 MHz? In other words, each cumulative sum represents the during that the signal is at high or low, if we divide the sum by the counter resolution (12.5 ns), we get the number of consecutive 1s (for high level) or 0s (for low level), once we concatenate all the 1s and 0s into one array, the samples we want are simply every 40th element of the array?

My questions are: do I still need to use the onboard buffer and where can I save the series of semiperiod intervals for post-processing? By using write to spreadsheet file vi?

Thanks,

Wesz

[Kevin_Price]

Yes, pretty much equivalent in that you can post-process the counter semi-period data to correctly re-create digital samples (high or low) at 12.5 nanosec resolution.  

At a highly detailed technical level, you may want to consider that the counter samples at the instant of transition, it doesn't "sample" at an instant of stable state.  When it finds a rising edge at, say, 100 nanosec, you may want to consider that to be a high-state "sample" occurring 1/2 interval later, i.e. at time 106.25 nanosec.  Dunno if it will matter to you this time, but it's good to have the habit of considering the distinction between catching a digital transition and sampling a stable digital state.

Once you get your full array of semi-periods, yes, you could write to spreadsheet file.

Unfortunately, there might be more bad news.  From the specs I can find on the site, it appears the USB-6221 may be *lacking* an important feature for high speed counter measurements that the USB-6210 supports.  The on-board FIFO seems to be only 2 samples long on the USB-6221 compared to 1023 samples on the USB-6210.  There's a chance I'm wrong here -- the pdf I found was for a 6221 but *may* have been written about the desktop PCI board before the USB version was introduced.  It's *possible* that the USB-6221 has an enhanced FIFO like the USB-6210.  If you have a manual that's specifically for the USB-6221, you can check the specs to be sure.

However, if you've got only a 2 sample FIFO and a USB connection, you'll likely run into trouble with high speed digital transitions.  The USB bus has too much latency to count on getting data off the board fast enough to avoid overrunning the FIFO.  When that happens, it's a fatal task error and all data gets lost.

-Kevin P

[weszh15]

Hi Kevin,

Thanks again. I don't think the transition will be a problem in my case since my original sampling rate was 2 MHz, which is way slower than the counter speed (80 MHz or 12.5 ns resolution).

I believe you are right, the FIFO for general purpose counters is 2 samples long. What if we use slower time base clock, say 20 MHz, will it relieve the overrunning issue of the FIFO? And how big is 2 sample? Is it 2 bits or something else? I am still confused on how data is saved into the FIFO. 

Wesz

[Kevin_Price]

The FIFO problem will depend on the external semi-period signal.  That's the signal whose edges determine the time of sampling.  What gets sampled is the 32-bit count value in the count register.  This goes immediately to the FIFO.  It must be confirmed via DAQmx to transfer successfully over the USB bus before 2 more samples are taken or there will be an error.

Since semi-period measurement takes 2 samples per pulse, you'll always get an error if a new pulse comes in before the data from the previous one has transferred.  The latency of USB becomes a serious issue for trying to move data off the board. 

This kind of stuff came up with desktop M-series boards on the PCI bus too, the bigger FIFO in the X-series was an important improvement.  (It was also added to some later-model USB M-series boards, making for the rare circumstance where certain high speed counter measurements could run *better* on USB than PCI.)

Deep breath.  Ok.   Taking a couple steps back now.  You said you're trying to get a power spectrum on a digital signal.  That sounded weird to me, but hey, I don't know everything so I rolled with it.  Now that we seem to be stuck, I've gotta go back and question it.  What is this signal you're taking in?  What's it coming from and what does it represent?  What do you expect the power spectrum to tell you?

Maybe there's some other workaround because it doesn't look like the methods discussed so far are likely to work with a USB-6221.

-Kevin P