Frequency weighting and cRio

[Patekkio]

I need to acquire acoustic data from 4 channels (9233 or 9234) with a cRio system. I must acquire sound levels both linear and A-weighted, and 1/3 octave spectrum.

I cannot transfer data from the FPGA to the host because of throughput limitations (4 ch's * 50 kHz).

So I need to perform calculations directly on the FPGA and therafter to decimate data before tranfer to the host. Is there anyone who has already implemented A-scale filter and/or 1/3 octave banks for FPGA?

thank in advance

Giovanni

[griffindore]

Hi Giovanni,

I don't quite understand why you can't transfer the data from FPGA to Host through DMA FIFOs. The throughput limitation of the PCI bus is realistically on the range of 100 MB/sec. My math could be terribly off here, but 4 CHs of 32-bit data (really 24-bit ADCs but we won't bit pack in this example) at a rate of 50 kHz should only require 800 kB/sec. You shouldn't have any problems with the throughput to the RT host.

I'm not sure if this will be helpful, but there's a Fixed-Point Octave Filter for FPGA (http://zone.ni.com/devzone/cda/tut/p/id/7761).

[Patekkio]

Hi Mike

thanks for your answer. Unfortunately I have the same problems as in http://forums.ni.com/ni/board/message?board.id=280&requireLogin=False&thread.id=1263

The Fifo transfer from FPGA to the Crio embedded controller seems too slow and doesn't keep up with  4 channels at full speed.

I can perform operations in the range of 40 kSamples total from FPGA to Host RT.

giovanni

[griffindore]

• Which cRIO controller and backplane are you using? 
• Are you using the "NI 923x Continuous DMA.lvproj" example found in the NI Example Finder? 
• What version of NI-RIO and LV FPGA are you using? 
• What is your DMA FIFO set to (i.e. data type and depth)?

[Patekkio]

I'm using 9004 and 9104 with LV 8.5

the Ni-Rio version is 2.3.1.

About the FIFO settings I tried some different configurations (anyway most typical 32767 and U32)

I can't find the example you're saying. Is it on LV 8.6?

My code is very similar to http://zone.ni.com/devzone/cda/epd/p/id/5817

of course I jus have the 9233 section

thanks

giovanni

[griffindore]

Hi Giovanni,

A lot of other stuff is going on in the RT VI in the example you pointed me to. This might be affecting things on your acquisition rates. I went ahead and downgraded the example from 8.6 to 8.5 and attached it below.

One thing I would recommend for you (although it's entirely up to you) is to upgrade NI-RIO to a version of 2.4 or higher (I'd recommend the newest version). This will allow you to read data from your cRIO modules in Fixed-Point Calibrated units so that you don't have to call Binary to Nominal on your host side. It also makes it easier to process data on the cRIO.

Let me know if the attached example helps out any. Good luck!

Message Edited by lion-o on 02-06-2009 02:58 PM

[Patekkio]

Hi Mike

thanks for your help.

Now here it's 10 PM so I had to get back home,

I'll be back tomorrow morrning.an try with your example.

thanks again

giovanni

[Patekkio]

Hi Mike

unfortunately everything's the same. Using the example supplied I can keep up only with sampling rate of 10 kHz! If it's higher the throughput is not fast enough

Giovanni

[griffindore]

Hi Giovanni,

I apologize for how long it's taken me to respond. I had to find the hardware so that I could try it out.

I do have some suggestions for you.

1. I was able to get this example to work by placing a diagram disable structure around the waveform graph in my RT VI. Keep in mind that the cRIO will run headlessly once you deploy it anyway, but running the interactive front panel is introducing a lot of jitter in the system and causing the processor to be sending the data through ethernet so that we can see it on a front panel. After disabling the indicator, I no longer encountered any overflows. 
2. When sampling at a rate of 50 KS/sec, I would suggest setting the Number of Scans to something close to 10% of the sample rate (i.e. 5000).
3. You may want to set the Host Buffer Size to a larger depth if sometimes you're still getting overflows. This would require editing the DMACalcs subVI to multiply by something more than 3 to calculate the Host Buffer Size. (This subVI is used in the "NI 923x Continuous DMA (Host).vi" )
4. Make sure you add seperate loops on your RT code to either process the data or transmit the data (including UI stuff). Keep in mind that our FPGA interface loop should be highest priority (you may just want to wrap a timed sequence structure around this loop and assign priority) and data transfer (network communicaton or logging) should be the lowest priority.
5. The 9004 controller only has a 195 MHz processor so I wouldn't be surprised if it can't keep up it's processing with the rate at which data is being acquired and sent from FPGA to RT. The 9014 has a 400 MHz processor and you may want to loook into upgrading to this controller at some point. Even this controller may not be able to perform the processing at the rate you need though, so you may still want to be looking for some FPGA IP to perform the tasks you need. Unfortunately, Sound and Vibration applications are out of my area of expertise. Do you have any LV code that implements the type of processing that you need?

Keep in mind that I used a 9014 myself to test this, so try some of the suggestions above to make sure you're capable of at least streaming from FPGA to Host at the rates you need. Then we can start looking at adding a processing loop if you already have some code that does the processing you need and we can see if that will keep up at your acquisition rates.

Regards, 

Message Edited by lion-o on 02-10-2009 01:59 PM

[Patekkio]

Hi Mike

thank you very much for your help.

Disabling nearly everything but the FPGA->host data transfer also my systems seems to keep up. For extra RT code probably I have to upgrade the system.

thanks again

Giovanni