Realtime smoothing of analog input signal

[Vrmithrax]

I have a cRIO application in a control environment, which is monitoring multiple sensors and discrete signals for controlling a high-speed piece of equipment.  This cRIO unit was recently installed as an upgrade to an original FieldPoint system.  We are now noticing that the analog inputs (4-20mA sensors sampling at 10ms) are displaying dramatically higher noise than they were with the FP unit.  I'm sure some of this is due to much better scan rates with the new system, but it is creating a problem with data visualization and some control calculations.

Can anyone recommend a good method for filtering out some of the localized noise in the analog signals that I am pulling in realtime?  I can't buffer and smooth, this is a system that requires immediate reaction times (under 50ms) to prevent damage and destruction.  I had hoped something like a point-to-point mean might work, but it does absolutely nothing.  If there are no canned functions or routines that would work, I am considering implementing a FIFO-style "5 scan average" that does buffer the previous 4 sensor readings with the current and provides the average (to limit localized spiking while keeping scan speeds high) but am not even sure of the best and most efficient approach for that method.

Any suggestions?

[JKSH]

Hi,

If you have the required toolkits, there are some built-in point-by-point filters or the PID Control Input Filter (5th order low-pass FIR) that you could try.

Another possibility is to let the FPGA sample the signal. It can easily sample at a much shorter period than 10 ms. Then, you can apply a low-pass filter or oversample+average the signal, then pass the filtered signal back to the real-time processor for visualization/control.

You hinted that you were using lower sample rates with your FieldPoint system -- you could also return to that sample rate.

Finally, what did you mean by the "point-to-point mean... does absolutely nothing"? It should have smoothed your signal (at the cost of increased latency)

[AndyClegg]

I would first try to understand why there is "dramatically" more noise now than before. Some ideas:

• Maybe there has been a mistake in the wiring to the new IO modules which has amplified the noise.
• Simply sampling at a higher rate should not change the noise - did you have anti-aliasing filters present before and they have been removed now ? If you are using the same anti-aliasing filters as before - they should ideally be changed for faster sample rate, but that should not give you more noise. If you don't have any anti-aliasing filters at all - then changing sample rate could change what you are seeing, but depends on noise at source. Try putting sample period back to what you had before.
• Some "noise" issues can come from timing jitter if your code isn't good.
• Are you seeing this increased noise in open loop - just to make sure its not a controller tuning issue ?

It is always much better to solve the real problem than try to mask it with filtering.

Point-to-point filter should work. Also, if you want very fast reaction times, you will need to be careful of any lag introduced by the filter, particularly in a feedback control loop.

[Vrmithrax]

Thanks for the suggestions, I'll look into a few of those filter options...  And I've had the electricians run through the wiring to make sure there are no external causes for the noise, but nothing is apparent.  It's incredibly odd, we replaced an old FieldPoint unit directly with a cRIO and a NI-9203 analog input module.  The wiring was not even clipped or adjusted in any way, just removed from one controller as it was being pulled out, and attached to the new controller.  The program is basically the same, and I have a very hard time believing that the old FieldPoint (not cFP, but original FP) could run that program more effectively than a cRIO-9074...

As for the Point-to-Point not doing anything, I even made a modification to allow adjustment to the sample size.  Whether I had a sample of 5 or 100, the signal looked exactly the same, with no change in latency.  It was very odd, because P2P always smoothed out signals in our older FieldPoint units.  Could it be an issue with incompatibility in a cRIO scan engine?  Or maybe something in the implementation has changed between now and the previous versions we were using...  Time for some experimentation, I guess.

[AndyClegg]

I don't know the original fieldpoint at all, but I'd be surprised it is identical architecturally to cRIO (FPGA + real-time operating system). I presume that your software has been modified to cope with the way cRIO works. Perhaps when it is used in Scan Interface mode it may look pretty similar to Fieldpoint.

Is the same noise present in open loop and closed loop ?
 

[srm@viewpointusa.com]

you are seeing the difference in input bandwidth between the old and new approach.  the noise that you are seeing has probably always been present in your system but masked by the original module.  the 9203 has a higher input bandwidth.

you can demonstrate this by doing a high speed capture of your signal using the 9203 module.  you will probably see noise generated by the switching power supply in the system.  you may make a difference by putting a hardware filter on your power supply.

the next step that i would do is to digitize the signal at more than twice the noise frequency on the FPGA and implement an lowpass FPGA filter on the signal so your slower control loop will not see the higher frequency noise.  anything else will be subject to aliased noise.

[Vrmithrax]

I was strongly suspicious that the old FieldPoint system just had a "natural filtering" effect due to the much slower internal sampling rate of the analog modules.  I had not thought of power supply noise being a culprit as well, though.  I think I still have a bit of that old-school "using amperage-based input sensors eliminates signal noise" mentality from all those years of dealing with PLCs in heavy noise environments...  Anyone have suggestions on what type of filter I should look for to try to clean up a potentially dirty 24VDC power supply signal?  I may pick some up right away, since I'll be back on-site at the system installation within a week.

As for the sampling rate on the FPGA, it's a very good suggestion, but that might be a lot trickier for our application.  So far, we've been running this system in strictly scan-mode only, not touching the FPGA.  It's definitely an area this system will be migrating into (I hate having all of that parallel processing power available and not using it), but it's a migration that will take a little time while we evaluate just how it could change our remote support capabilities, and what adjustments we might have to make to implement FPGA into our strategies for the product.  Unfortunately, the systems we support are spread out all over North America (and potentially South America and Australia), and it is often luck of the draw on whether we have any method of network connectivity into the systems for remote support...  We often have to sacrifice a little performance for easier support.

[srm@viewpointusa.com]

I am currently using a Schurter FMAB-MRYB-1010, your current requirement may vary.

this turned the switching ps into the noise equivalent of a linear.