onboard digital integration

[caz]

Hi all,

I have an application where I have a repetitive 30 kHz waveform (WF). This waveform is comprised of 10 individual pulses. What I'm interested in measuring is the area/integral/riemann sum/energy or whatever you want to call it of each pulse in the 30 kHz WF. One method would be to oversample and then compute this in software. A sample rate of 20 MS/s and above should get the job done. Obviously, the faster the sample rate the better the integral will be. However, I have 7 separate channels of similar WFs so the 5105 board with 8 simul sampled channels would be one choice. The downside of this method is record length. At the max rate of this board and with 7 active channels I think a total record length of ~0.6 sec is possible. In reality, what I really need is a sample rate of 300 kS/s (one sample for each of the 10 pulses of the 30 kHz WF) and then the record length will reach my requirements. The 5922 is one step closer by oversampling and then filtering and decimating. I haven't entirely ruled this approach out but instead of filtering and decimating it would great if I could get decimation through summing. Is there anything out there that does this? I don't think the 5922 will work since the bandwidth of the filter varies with sample rate. In essence, what I need is a digital summation in hardware so that I can either take longer record lengths with onboard memory or allow the capability of streaming to disk/ram without bus bottlenecks. Any thoughts, inputs, suggestions would be helpful. Also, I don't necessary need all 7 channels on one board (hence the mentioning of the 5922) but all will need to be strictly synchronized.

caz

[Speedy_Badger]

Hi caz,

Let me see if I can address what I think are your two main questions:

1. How can I integrate the pulses acquired by the digitizer?

The easiest way to do this would be in post processing. We currently do not have a digitizer which will do what you want on the hardware itself. What we can do however is take measurements on the data after it is fetched from the onboard memory. You could either use the scalar or array measurements built into the NI-Scope API, or implement you own custom code that calculates what you need. You are correct that the record length on the 5105 with maximum memory and maximum sample rate would be roughly 0.6 seconds.

2.  Can I have a HW based summation of my signals?

Summation of the signals would have to be on post processing. We have an array measurement built into the API which sums multiple channels however, as before, this measurement is done post fetch of the data from the device. Also in regards to the 5922, the resolution changes over the frequency range, not just the bandwidth.

Overall, it seems like you are on the right track in terms of ideas; oversampling or filtering and decimation. It is important to note which aspects will be available in hardware or software. I have a few additional questions for you to help me get the best information to you.

What is the record length that you want?

You mentioned continuous acquisition and streaming, is this a streaming application?

Is there an explicit need to do the processing in HW? (i.e. is your application time critical?)

With more detail about your application and what you want to do exactly I can better point you to the useful resources.

Regards, 

[caz]

Thanks for the reply Chris.

I think your answer cleared this up for me. It appears that there is no NI hardware that can do exactly what I want. To answer your questions;

1) What is the record length that you want?

For the oversampling case, I would like to have at a minimum 5 sec of data. For the 5105 at 60 MS/s on 7 channels, this would be ~ 4 GB. However, I don't really need all the data, just the sum of every 200 pts at the 60 MS/s rate. This reduces the overall data memory to 21 MB (for 5 sec) which is the motivation for exploring hardware integration. Not to mention, at this reduced overall data rate of 4.2 MB/s any bus will keep up so essentially this application could run until either RAM or the hard disk is filled.

2) You mentioned continuous acquisition and streaming, is this a streaming application?

I think I answered this above

3)Is there an explicit need to do the processing in HW? (i.e. is your application time critical?)

Again, I think this is answered in 1 but yes, the application is time critical. However, the overall time of the application will vary but the repetitive 30 kHz waveform will always be constant. This waveform of 10 pulses contains the information from the test so in the end we will be extracting 2 experimental parameters at 30 kHz.

This first system with 7 channels will be a proof of concept with later tests requiring up to 50 channels requiring the DAQ to be as efficient as possible.

regards,

caz