Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Number of samples is much larger than onboard buffer size

Hi Kevin,

 

You mentioned that each pulse takes two samples, is it because each pulse contains a high time and a low time, i.e., four edges, and each time interval corresponds to one count value? The minimum semi-period of my signal is 1/(2 MHz) or  0.5 us, if it still causes USB latency, I don't know the purpose of including 2 counters on the board.

 

The digital signal is the output of an analog-to-digital converter chip I'm testing, which runs at 2 MHz. I want to collect enough samples and take FFT on them to plot the spectrum as well as calculating the signal to noise ratio and some other parameters so that I can evaluate the performance of the chip. 

 

All I want is collecting the digital output at 2 MHz.

 

Thanks,

 

Wesz

0 Kudos
Message 11 of 16
(562 Views)

Semi-period measurement latches & buffers a sample on every incoming edge.  A 2 MHz clock would result in a 4 MHz sample rate (0.25 usec)  b/c both rising *and* falling edges get used to store samples.

 

 

You're talking about sampling the digital output of an A/D converter.  I would expect a good # of bits resolution there, but back in msg #5 you said you were only sampling 1 bit.    All the counter talk was predicated on having only 1 bit.  If you've got a bunch of bits, counters won't be a good approach.

 

So back to the need to capture a digital port full of bits at 2 MHz sample rate.  My best next guess at something to try is to divide down the external 2 MHz clock from the ADC using a counter on your DAQ board.  Let's say divide by 4, that's the smallest easy divisor to configure.  That counter is now putting out a 500 kHz clock that's synced to every 4th clock from the ADC.

 

You can now set up your DI task to use your own counter's output as a 500 kHz sample clock.  Does the original analog signal in question truly need you to sample faster than that?  Or maybe you can get away with an even slower rate, and have better likelihood of moving the data over the USB bus without a task error?

 

Bottom line is that your board *can't* take digital samples at 2 MHz.  You'll either need to make compromises to keep using your board or look for another capture device.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 12 of 16
(552 Views)

Hi Kevin,

 

Sorry for any confusions in my previous posts. The chip I'm testing is a 1-bit A/D converter. I guess the "bits resolution" you mentioned is the effective number of bits (ENOB) of an ADC. The ADC output either changes or maintains its state at the rising edge of the ADC clock, so the minimum semi-period is one period of the ADC clock (Please take a look at the picture I attached). I want to "copy" the exact digital waveform of the ADC output (100111011..., which is a 1-bit digital sequence from my perspective) and send it to PC for post-processing. That's why I am trying to sample the ADC output at 2MHz (synchronized with the ADC clock). 

 

Thanks,

 

Wesz

 

0 Kudos
Message 13 of 16
(548 Views)

Ok, I see.  From what I can tell, you can't there from here with the USB-6221.  The DIO subsystem can't support 2 MHz sampling and the counters can't support the needed data transfer bandwidth.  You'll need to use a different capture device.

 

I'd look first at something in the PCIe X-series 636x group.  They'll support 10 MHz for DIO, as well as give you many other capabilities for analog IO, static DIO, and counter features.  There are probably other dedicated digital boards that can capture at 2 MHz but I don't know that family of products as well.  There are likely some cheaper options outside of NI if you've got more time than money, time needed due to the learning curve of a different product, different API, different gotchas to stumble over while trying to get it to work, etc.

 

 

-Kevin P

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 14 of 16
(544 Views)

Hi Kevin,

 

Okay, thank you for your help so far. I am curious what kind of signal (how fast it could be) is applied to semi-period measurement and what is minimum data transfer bandwidth for USB-6221?

 

Wesz

0 Kudos
Message 15 of 16
(541 Views)

All I found was some ad-hoc benchmark info, albeit pretty trustworthy coming from an knowledgeable NI insider.   Your USB-6221 would be most similar to the USB-625x because they both have the small counter FIFO.  Realize that such performance is strongly system-dependent, and much has changed in the last 10 years.  While hardware tends to get faster, the USB spec hasn't changed and Windows 10 is probably "heavier" than XP.  So it's tough to predict overall.

 

 

The best bet to *try* to use the USB-6221 (and I don't honestly expect it to work reliably) is to set up the semi-period task I outlined in msg #6, except you'd probably use your 2 MHz clock as the timebase instead of an internal 80 MHz timebase.  As I understand your application better, the sync of the 2 MHz clock is more important than the resolution of the unsync'ed 80 MHz internal clock.

 

The counter can definitely *count* at 2 MHz, it just can't *sample* at that rate for any sustained time.  Using the bit as the effective "sample clock" in a semi-period task, you'll end up with a variable sample rate that'll probably be a little shy of 1 MHz average.   Probably still too fast, but at least it'll average less than 2 MHz and never exceed it.  That gives you more of a chance than a straight 2 MHz rate.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 16 of 16
(537 Views)