Remove spikes from Load Cell readings

Question

I have developed load indicator interfaced with load cell to display the value of load. The device is to be used in on-line weighing of a bag that is moving over the conveyor. Due to the mechanical movements there is a spike in load reading and in order to remove those spikes i need to implement software based filter to stabilize the readings.

Can anybody point me to the right direction, on where to start ? I am using 8051 micro controller and ADS1231 ADC for converting the analog voltage levels to load value.

Answer 1

These things happen in checkweighers all the time and the common way around this is for the software to simply ignore the glitch i.e. throw away those readings that look suspicious.

A lot of checkweighers also use an optical device to sync the software up with the position of the "thing" to be weighed thus the software knows when it should be using readings to calculate weight.

This problem is usually due to cantilever resonance as the "thing" initially slides onto the edge of the weigh-part of the conveyor.

I reckon you should show a picture of weight results versus "thing" position as it passes over the weighing section. This will allow further analysis by me and others. I recommend that you have an ADC rate that would take several tens of readings (if not hundreds) as the thing passes through the weigh section.

Answer 2

You don't need to 'remove the spikes' so much as 'give the right reading'.

There are at least two good possibilities for what's happening, and they require different software filters. Then there are bad possibilities, that may require a rethink of the mechanical arrangement.

The difference between the two that can be handled in software depends on the sample rate and the sensor bandwidth. If you are sampling above the Nyquist rate for a low-pass bandlimited sensor, and your sensor is linear, then the correct filter is the mean. The spikes are part of the correct reading, and are required to balance the low readings you get either side of the spikes.

If you are sampling well below Nyquist on a wideband sensor, and the correct reading is 'most of the readings', then you do indeed need to reject the spikes. As long as the number of spikes is well below 50% of the readings, the simplest filter to use is the median, that value for which 50% of the readings are above and below. This will be slightly biassed, but not as much as a mean filter.

If you can identify the spikes and remove them from your data set before filtering, then the median will be much less biassed, and still less sensitive to any errors in the spike classification process than the mean.

If you have a situation which is neither of these extremes, then it will be very difficult by straightforward software filtering to recover the true forces, as you have contaminated the measurement at the sensor.

Answer 3

A FIR filter or moving average filter, when your bag strikes a photocell, you have an average of measurings. The averaging time is the time that bag travels on the weighing platform before striking the photocell.
Other possibility is to have FIR lowpass filter and sequently averaging filter. You sample at high freq, use FIR to eliminate HF noise, then you use this filtered signal to pass it into averaging filter. Perhaps you should see DSP forum.

Answer 4

Filtering problems are best handled by first capturing the data that comes in on your ADC and then analyzing the nature of your signal. A graph of your data in a spreadsheet is invaluable for analysis because you can apply proposed filters in the spreadsheet and see what the outcome will be and if it is what you want, thereby saving you a ton of code-and-churn.

Once you determine what aspects of the data stream are desired and which are not, you should select and tune your filter (or data validation algorithm) for that application.

This is a standard engineering approach to a problem - find, analyze, simulate, implement, repeat until done. I find that embedded engineers are usually light on "analyze" and forget "simulate" entirely, thereby forming a find-implement-repeat churn.

In embedded systems, the first problem is usually getting the data out for analysis. I learned to slip in a high-speed data port for the purpose of telemetry on designs on prototypes to help with these problems, and FTDI is usually what I turned to - just need a spare UART on the micro and a bit of board space for the FTDI chip and a micro-B connector. You can depopulate the port for production, and if you wire USB power up, you've made your desktop debug kit a bit easier to power up.

A lot of your filter options and tuning will depend on the relationship between your sample rate and the duration of the glitch waveform. You have to determine when a glitch is no longer a glitch but a real phenomenon that you want to respond to.

I think that if you can see your data stream in a spreadsheet, the solution will quickly present itself.