LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

high speed pulse counting for intensity image generation

I'm trying to count TTL pulse signals that have a repetition rate varying between 0-50MHz over an interval of time.  I then convert this count number into a row of integers to generate one line of an intensity image, and then repeat.  The problem I'm having is that the count number is extremely low.  I'm guessing that this has something to do with my sampling rate.  In order to generate my 256x256 pixel image in 4 seconds, I need to sample in powers of 2.  Currently my DAQAssist is set to 16,384 samples to read at 1,048,576 samples/sec.  Unfortunately I believe this sampling rate is too slow to recognize all the pulses because the software only counts a maximum of around 40 pulses, but a larger sampling rate causes my program to give some error about converting adc too fast.  Is there a way to fix this and allow a much faster sampling rate?  I am using a PCI-6259 acquisition card.  Attached is my vi.
 
Thanks,
Anthony
0 Kudos
Message 1 of 6
(2,498 Views)

It doesn't appear that a 6259 can handle TTL at 50 MHz.  You'd need to sample at >100 MHz.  It's not clear how many channels you have, but assuming that it's one channel per column in your image, you're stuck with:

Analog Acq: (1 / # channels) MHz sampling rate, supports 1-32 channels.

Correlated Digital Input: 10 MHz sampling rate independent of # channels, supports 1-32 channels.

Counter / Timer: Accepts external inputs <= 20 MHz, limit of 2 channels.

 

My recommendation: Buy one or more PCI-6602 counter / timer cards.  Each will provide you with 8 channels for the TTL pulses.  These boards support a feature called *prescaling* which can divide down an external signal of 100+ MHz by a factor of 8.  (I haven't used the prescaling feature with multiple channels but I *think* you can use it on all 8 at once.) 

Supposing you sample every 10 msec.  The data acq board's hw counters increment based on the incoming 50 MHz pulses.  You sample that count value only 1 time each 10 msec, producing data for yourself at a rate of (# channels)*(100 samples / sec / channel)*(4 Bytes / channel).

Compare that with AI or hw-clocked DI at 100 MHz.  You'd get a data rate of (# channels)*(100e6 samples / sec / channel)*(1 to 8 Bytes / channel), which probably isn't even possible on a PC.

-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 6
(2,493 Views)
Thanks for the info Kevin.  Looks like I'll need to change up my system.  My prof is telling me to use hardware counter chips as an alternative, and then send those into a digital-to-analog converter for analog acquisition.  I can then convert the analog voltage back into whatever integer count that the DAC had read.  By the way, how did you get the formula for maximum sampling rate for analog acquisition based on the number of channels?  I was actually planning on doing a 32-channel simultaneous analog acquisition, but if I'm limited to a 31,250 Hz sampling rate then my results would have been horrible if I had continued setting things up.
 
-Anthony
0 Kudos
Message 3 of 6
(2,490 Views)

1. The sampling specs for the 6259 can be found by following the "Specifications" link(s) on its main product page at ni.com.  It lists 1 MHz (aggregate) meaning that with 32 channels, you'll get a A->D rate of 1 MHz split among them, i.e., 31.25 kHz per channel.

2. What's the rationale for doing D->A and then A->D?  Is it because of the channel count?  You'll be introducing some error with this method.

3. Guessing that your channel count is 32 as you previously mentioned, your alternatives look like:

A. Build circuit board with 32 hardware counter chips and 32 DAC's to produce 32 analog signals proportional to counts.  Counts must be resettable based on the A->D strobe.  Spend a *long time* designing the board, getting it fabbed, and then hanging out with solder iron and o'scope getting it all debugged.  Use 6259 to clock in 32 Analog signals.

B. Buy 4 PCI-6602's, 4 terminal blocks, and 1 RTSI cable.  Spend a couple days or so adapting an example program to directly read 32 count values free from the D->A->D noise.

-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 4 of 6
(2,484 Views)
Yeah minimizing costs is one of our main focuses and the counter chips were just a few cents apiece.  Doing D->A, then A->D allows the counter chips to do the high frequency counting using a single channel.  The ones we have in our lab can count at a rate of 75MHz.  We send the 16-bit digital count into a DAC to generate a voltage after the proper integration time has passed, then read the voltage into our computer.  This allows us to use a single channel for each 16-bit digital count.  Our plans were to multiply this into 32 separate counter circuits (essentially what you've listed in plan A).  We've been playing around with 1 channel right now, and have started running into the errors during conversion you have mentioned.
 
Since the max sampling rate using all 32 channels is only 31.25kHz, we'll probably need to end up following your plan B since 31.25kHz is still too low using our D->A->D method.  Our goal is to read and generate 32 different 256x256 pixel images simultaneously in 1 second.  this would mean that each pixel needs to be read and completed in approximately 15.25 microseconds for all 32 channels, resulting with a maximum pulse count of about 762 per pixel per image.
 
I'll pass this information along to my professor.  By the way, what are these 4 terminal blocks that you've mentioned which should be used with the 4 PCI-6602 cards?
0 Kudos
Message 5 of 6
(2,479 Views)

FYI, there are probably plenty of other alternative ways to approach your problem other than what you or I have come up with so far.  For example, I initially thought of this purely as a standard analog / digital acquisition problem, where the assembly of data into an image was just a visualization option.

In any event, to the extent you're considering LabVIEW or NI data acq boards in your solution, I'd highly recommend calling your local NI Sales/Tech Rep.  You'll be able to have a much more detailed conversation which will lead to a more optimal overall solution than I'm liable recommend.

There are different possible cables / terminal blocks for the 6602, but if you've got a tight budget you may be surprised -- the combo I have normally ordered costs another $450 per board (2 meter shielded high-speed-digital cable, SCB-68 shielded terminal block enclosure).

-Kevin P., out here in a good-sized company, where the money value of time is typically much much higher than in university.

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 6 of 6
(2,473 Views)