PCI-5105 and automatic pretrigger rearming

[JSnyder]

Hello,

I am working on a project with the following data acquisition specifications:

1.) 10 MSamples/sec/channel on 4-5 channels.

2.) Acquisition of at least 5k events/sec/channel where an event is an analog pulse 10 microseconds in durations.  The events are randomly spaced.

3.) Acquistion of the complete event shape for area under the curve measurements.

4.) LabVIEW as the programming language.

5.) DAQ board resides in a Windows PC (1.79 GHz Pentium, 1 GByte of RAM).

I have recommended the NI PCI-5105 (the 16 MByte onboard memory version) to fill these requirements.  What I would like to do with this card is to set it up to acquire the pulses in pretriggered mode and have the board automatically rearm itself after each event acquistion (no software rearming).  I would then analyze the peaks in software for peak height and area.

Will this board do the above?  Am I going to run into bandwidth problems when trying to retrieve the data from the board?  The total throughput should be (10 MSamples/sec/channel * 5000 events/sec * 10 microseconds/event * 5 channels) = 2.5 MSamples/sec.

Any advice or recommendations would be greatly apreciated.

-John 

[Matthew_W]

 Hi John,

1. The digitzer has 60MS/s bandwidth, divided by the number of channels to digitize and we have enough bandwidth to acquire 10MS/s for 6 channels.

2. The acquisition of 10uS pulse @ 5k events/sec is possible, there is a trigger re-arm time that should be accounted for. This is addressed on page 11 of the manual.
    What do you plan on triggering from?
  

3. By the complete event shape you mean the entire waveform?

The board with 16MB of onboard memory can acquire 6202 samples to the onboard memory. This calculation can be found on page 15 of the manual.

The retrieval (Fetch) of the data from the board to Labview memory should not be a problem.

Would your application be to take as many samples as possible then fetch them to memory?

The total throughput calculation seems correct. The PCI bus has a bandwidth of 133MB/s, should be no problems there.


Have a great afternoon,

MatthewW
Applications Engineer
National Instruments

[JSnyder]

Hi Matthew,

thanks for the info. 

>  What do you plan on triggering from?

We are going to be triggering on the analog signal on one of the channels.  This is a flow cytometry project which involves detecting cells as they pass through a number of laser beams seperated in space.  The interaction between the lasers and the cell (fluorescence or scattering) is detected by a series of PMTs.  So, the cell crossing the first beam/PMT pair would serve as the trigger and events will be seen on subsequent PMTs at times after the trigger as the cell flows through the cytometer.

> 3. By the complete event shape you mean the entire waveform?

Yes.  We need the complete waveform of the triggering event as well as subsequent events seen on other channels.

> The board with 16MB of onboard memory can acquire 6202 samples to the onboard memory. This calculation can be found on page 15 of the manual.

I'm not quite sure how you are getting 6202 from this equation.  By my calculations, 6202 samples * 2 bytes/sample * 1 MB/1048576 bytes = 0.0119 MB.  From my throughput calculation before, I will be putting 2.5 MSamples/sec into the onboard memory, which is (2.5 MSamples/sec * 2 bytes/sample *1 MB/1048576 bytes) =~ 4.8 MB/sec.  So I should be in good shape if I fetch data from the board ever 0.2 seconds or so.

Thanks again for the info... I didn't realize that the 60 MS/s was divided amongst all the channels.

-John

[Matthew_W]

 Hi John,

 I mis-spoke earlier when I stated the PCI-5105 has a sampling rate of 60MS/s that is aggregate. That was incorrect. The sampling rate of the PCI-5105 is 60MS/s per ADC, where the
PCI-5105 has 8 ADC's,it has a total sampling rate of 480 MS/s.

The calculation for on board memory sample size is the following:
 
  1. max # of records = size of memory option / 256 = 16 MBytes / 256 bytes = 62500
 
  2. max # of records = (# samples * 2 * # channels sampled) + 480
 
      max # of records - 480 = (# samples * 2 * # channels sampled) = 62500-480 = 62020
      62020 / (2 * # channels sampled) = # samples
      62020 /  ( 2 * 5 channels) = 6202 samples

I made the following assumptions:
   1. sampling from all channels the same amount
   2. 5 channels sampled
  
However fast you will fill up the 6202 samples will be determined by your sampling rate.
  At 60MS/s, then:
  time = samples / rate = 6202samples  / 60Msamples/s = 103uS
  At 2.5.MS/s then
 time = samples/rate = 6202 samples / 2.5Msamples/s = 2.481mS

Sorry for the confusion John!

Best regards,

MatthewW
Applications Engineer
National Instruments
 

[jswalwell]

Hi,

Was John's question regarding trigger rearming on the 5105 ever answered?  The manual states 2.4 us, but the only way I have found to rearm the 5105 trigger (either single or multiple record) is to run the ni-scope initiate.vi in a loop.  However this is slow because it's software rearming what is effectively a "single" trigger rather than the hardware running in a "normal" trigger mode...I'm using oscilloscope trigger lingo here.  The 5105 can be configured to grab multiple records (equivalent to a storage o-scope), but in order to trigger continuously initiate.vi has to be run again to restart the acquisition.  Using this method I've been able to get the card to acquire continuously very quickly, but there is an inherent delay and loss of data while initiat.vi runs.

[John_P1]

Hi jswalwell,

You are correct in that the 5105 requires a 2.4 us rearm time for triggering.  You shouldn't have to run the initiate.vi in a loop to rearm the trigger (this would be very slow).  Using a multi-record fetch, you are actually acquiring each record based off of the trigger.  The records are stored in the 5105's onboard memory until retrieved with the Fetch vi.

If you are triggering at a fast rate, I would recommend to look at the example:  NI-SCOPE Fetch Multiple Records at Once.  This will allow you to continuously fetch (fetching multiple records at once will allow your software loop to keep up with the data).  Let me know if you have any questions or any problems implementing this example.  Thanks for posting!

-John 

[Josefin]

Hi,

I just realized that this thread is dealing with the exact problem that I have right now. I also use the 5105 board and are having trouble with getting the system to rearm as fast as the data specifications say it can.

In my applications all my 6 boards (with 8 channels on each) must be synchronized and ready to fetch multiple records up to 1500 times per sec. Each record is 550 us long and has a samling rate of 1MS/s. Hope you get what I mean. I'm not 100% sure about the commonly used terminology here. Anyhow... According to the system specifications this should be possible. It should actually be able to do 1/((550samples+2,4rearm)E-6)=1810 records per second (96 MB/s). In order to synchronize the cards I use the niTClk Initiate.vi to initiate each record and niSCOPE Multi Fetch Cluster.vi to aquire the data from the boards. Unfortunately I can't get the initiation vi to work more than once if it is placed outide the acquisition loop. If it is inside the loop, everything works perfectly except for the quite slow rearm time (maximum 200 records per second).

Here is my question: Is the solution of fast rearm time in the NI-SCOPE Fetch Multiple Records at Once. example possible to use also in my application? Since niTClk Initiate.vi isn't used in that example I just wonder if I should be able to use the same approach also if multiple cards with all channels needs to be synchronized. It would be great to get the niTClk vi outside the loop some how, if that is what slows everything down.

Any help on this topic would be very much appreciated!

Best regards /Josefin

[John_P1]

Hi Josefin,

Re-initiating your task inside a loop can take several milliseconds. The Fetch Multiple Records at Once example should work for you since it moves all of the configuration outside of the loop.  When using T-Clk, you would also call the T-Clk functions outside of the loop--once T-Clk is configured you should not need to continuously call the functions.  I recommend you try the example with a single board to make sure that it works the way you expect, then try adding in the T-Clk functions.

-John 

[Josefin]

Got it! Thanks a lot!

I followed your advice and the speed is significantly higher now. So far I only tried one channel though. The system can now acquire 986 recordings per second. Maybe it it possible to make it even faster, but I'm not there yet. Just hope that the synchronization of the 6 boards also works with this solution. Thanks again and Merry Christmas!

/Josefin