Digitizer for continuous data acquisition

[jolv]

I'm completely new to digitizers etc so please bear with me.

I'm trying to select a card that will fulfill the following requirements.

• I need that digitizer that I can do continuous data acquisition with and concurrently get the data off the card.
• I'm only processing a video signal of pulsed data, a 100MHz sample rate will be more than sufficient. 
• I don't know what the pulse duration is going to be (but it will be mostly around 0.1 - 5us) but could be much larger.
• Edge triggering will be sufficient, although some pre-trigger (and perhaps post) samples might be useful.
• I need to process the pulses in real (or near real) time.
• Most of the time there may not be any pulses.
• Sometimes there could be 100,000p/s continuous for several minutes.
• The implication of real-time is that if I receive just a single narrow pulse (and nothing after it) then I need to know about it almost immediately, ie. I can't wait for a buffer to fill up before finding out about the pulse and being able to access the data for it.
• An 8 bit digitizer will probably be enough, but more bits is OK (if that's the only alternative).

So the question is is there a digitizer that will let me do all this?

If there is do I have to use LabView or can I just write in C++? 

I suppose the other alternative (which I've also been looking into) is to simply continuously stream all the data samples to a host computer and process them in software there. So at 100MHz that's a lot of sample data, but I believe that could be transferred across a PXIe bus. Of course the other issue is whether the host computer software could process it fast enough.

The other alternative is of course a digitizer with programmable FPGA to do the processing and queuing of the pulses, but I didn't want to go down this route if I can avoid it.

Any suggestions?

[jolv]

One item I forgot to mention/ask, is that I think all the cards have a 'dead' time when after triggering on an event (a pulse) they have to rearm for the next trigger (pulse), and during this time the card is 'dead' so if a pulse is received during this period it won't be detected. Is this correct?  I think, for example the rearm time on the NI 5112 is 2us.

[jolv]

OK I'll reply to my own post (again) as I can't see how to edit it !

My latest idea is to use the NI 5122.

It does have a minimum time between between pulses of 2μs because of the trigger hold-off. I have yet to decide if this is acceptable.

The advantage of using the 5122 is that it is PXIe, so if I decide I can't live with the effective trigger re-arming delay I could in theory simply stream all the data samples across the PXIe to say a 8106 processing board. There I could process all the samples in software. The processing is trival, just keeping samples over a certain threshold and create a 'pulse report' which I would then send onto a user workstation.

 Question now is could I do that just using Windows XP (Linux isn't an option is it with NI cards?) or would I have to use a RT OS like IntervalZero's ETS ?

[Jennifer O]

Great conclusions Jolv.  I think the NI 5122 is a great place to start. 

The PXI Express option does give the flexibility to perform continuous acquisition at full rate OR multi-record acquisition with a record for each of your pulses.  With the edge trigger and multi-record mode you can configure how many pre and post trigger samples you would like to collect.

I would like to add that there has been a spec update on the NI-5122, changing the minimum rearm time to 3us (when TDC is off).  This may affect your decision to use the continuous or multi-record options.  If there is an extended period between some pulses, you will want to add a step to read the fetch backlog to determine how many records are available before you attempt to fetch them, otherwise you could get a timeout error waiting to fetch data that is not yet available.

While I am partial to LabVIEW, C++ is also an option.  LabVIEW has some signal processing tools to monitor waveforms and perform limit testing that might help you with your application.  It is also easy to implement a secondary loop to perform the processing step and take advantage of dual core processing.  This application sounds feasible within the Windows XP OS, but if you would prefer you can run LabVIEW Realtime.  There is a Linux driver as well for a subset of the digitizers available from National instruments, this however does not include the PXIe-5122.   You can read more about this in the readme for the NI-Scope 2.9 for Linux driver. (http://joule.ni.com/nidu/cds/view/p/id/927/lang/en)

I recommend speaking to your National Instruments Sales Rep as well before making a decision.  They are a good reasource to work out some of the details, although you seem to be doing a great job yourself.

[jolv]

Hi Jennifer, thank you for your reply, I at least feel like I am on the right track. I am speaking to a NI technical person as well now.

I'm actually investigating using a RT OS to process the data to remove the non-determinism of using XP - NI suggested the Pharlap OS (which is IntervalZero's ETS I believe). They have optimized drivers. Just wondering if anyone has any comments on ETS, it doesn't look like it should have to much of a learning curve.