High Speed Filtering Options?

[Daklu]

I have a cRIO-9074 with a 9237 strain gauge module. The signals are way too noisy to be useful, so I added a Butterworth Pt-by-Pt low pass filter to the RT code. My benchmarking shows the execution time of that vi to be 0.1 ms on this platform. That gives me a theoretical maximum throughput of 10k points per second.

The first problem is I'm going to have 8 channels of data and the minimum sample frequency for the 9237 is 1.613 kHz per channel, which translates to ~13k data points per second. I considered moving the filter to the FPGA, but there doesn't appear to be a way to change the sample rate without recompiling the code. At this point in the project I can't really afford to wait 20 minutes for the recompile to finish every time I make a change. Perhaps later in the project when systems and parameters are understood better I can do that.

The second problem is I don't have enough signal processing experience to understand all the filtering options LV provides. The customer is leaning towards using an FFT to filter out high frequency noise. I don't know if that will be any more computationally efficient and I'd have to do a bunch of research to even figure out how to use those vis to do what I need.

Does anyone know the relative cpu load of the various filtering options, and are there other filters that can give me a low pass filter at a much smaller cost?

[JamesMc86]

Hi Daklu,

I would aim to get something like this on the FPGA, I don't understand what would need to change that often once you have it down. Do you mean changing the sample rate of the module or the filter? Don't have the filter VI in front of me but you can change the sample rate of the module without a recompile by using an IO property node on the module.

In terms of relative requirements I haven't tried to many. I would expect some form of FIR filter to be pretty efficient. I think anything that requires an FFT and back is going to be pretty resource hungry.

[ShaunR]

Depending on the type of noise; a running average or median filter might suffice.

[Daklu]

I would aim to get something like this on the FPGA

Yeah, that's what I ended up doing. It wasn't as troublesome as I thought it would be.

Don't have the filter VI in front of me but you can change the sample rate of the module without a recompile by using an IO property node on the module.

Right, but for the filter to work correctly it has to know the sampling frequency, and that can only be set using the express vi configuration dialog box.

What I ended up doing was setting the filter's sampling freq to 1.613 kHz and the cutoff freq to 2 Hz. I believe the only side effect of increasing the module's sampling freq is a proportional increase in the cutoff freq. i.e. Collecting data at 10 kHz would push the cutoff freq to ~12.3 Hz. It's not ideal, but it's workable.

Another option would be to decimate the input stream to a fixed sample rate prior to running it through the filter. But with the huge number of possible sample rates the module supports I didn't feel like working through the math to make sure I'm getting consistent and regular data.

[JamesMc86]

This maybe a non functioning brain on a saturday, but is that filter going to do anything? Sampling only gives you frequency content at Fs/2 so you can't have frequency content at that level, if it is there in the analog domain it will already have aliased to a lower frequency in the digital domain. You would need to over sample then filter at the desired point if you are trying to avoid aliasing.

[Daklu]

is that filter going to do anything?

My fault for mixing units. Sample rate is 1.613 kHz. Filter is 2 Hz.

Right, but for the filter to work correctly it has to know the sampling frequency, and that can only be set using the express vi configuration dialog box.

I happened to run across a Butterworth Coefficients vi while reading the help files that addresses this problem. I run this vi on the host with the sample and cutoff freqs as inputs and pass the returned coefficients to the FPGA. This allows me to change all the relevant parameters from the RT code without recompiling the FPGA code.

[JamesMc86]

Ah yeah must have been skim reading! Pleased you found something to work.

[AlexA]

Is it completely infeasible to filter at the hardware level? You should filter as early as possible and as James mentioned, you're going to have problems with high-frequency noise aliasing down. It's relatively simple to construct an active low-pass filter that you can tack in-line, but you could probably even use a passive filter.

[Daklu]

Is it completely infeasible to filter at the hardware level?

No, it's not completely infeasible, but since we're in the development phase and don't know what the optimum filter values should be I'd prefer to have the flexibility of software filtering.