Ring Buffer to implement simple lowpass filter

kein · Joined: 23 Jul 2007 Posts: 103

Hi Guys,
I would like some help on the implementation of a ring buffer. I've a data coming from adc and wouldlike to apply a simple FIR filter to the data. That's a a signed ring int16 buffer of size 50 would be a good enough.

What I want to do is read 40 samples from the ringbuffer into a processing array while the ringbuffer continuous to fill up in an interrupt subroutine. the interrupts occurs every 10ms and adc should be read into the ringbuffer.

I should then apply a filter to the processing buffer while the ringbuffer continous to fillup. My sampling frequency is 100Hz and my signal of interest is between 1-2HZ. My PIC processor is 18F4450.

Any help please is welcome...
Kind regards

Ttelmah · Guest

The FIFO buffer used in the EX_SISR example, is a basic ring buffer design.
I'd suggest you make the size 64 words (rather than 50), or alter the way the 'remainder' calculation is done, since the example, is 'inefficient', if not using a binary buffer size. This design will work just as well with 16bit data as the 8bit data it currently handles, by simply changing the size of the array elements.
Instead of driving this with the external serial interrupt, simply use a timer interrupt to trigger the acquisition. I'd suggest that you have your reading 'lagging' by one, so when you arrive in the interrupt, you read the last ADC value acquired, then trigger a new acquisition. This way the code won't have to wait for the ADC.
The real 'work' will be in calculating the FIR filter. Are you using a DSP PIC, or a basic design?.

Best Wishes

kein · Joined: 23 Jul 2007 Posts: 103

Thanks Ttelmah for your response. No I'm not using DSP chip however I'm generating filter coefficient in MATLAB (fixed point math) and then store them into a buffer. The algorithm is as shown below however something is not working properly. I don't know if this has to do with circular buffer or not.
What im doing is to wait until the difference between the head and the tail is equal to 8 and then begins to take a reading from the circular buffer.
But this doesn't seem to go well any help?

Ttelmah · Guest

Without looking very far, you are going to get a problem with subtracting 0x266, from the ADC value. If the value goes below 0x266, you are going to get a massive positive result. You either need to cast the ADC values to signed, and use a signed int16 to hold the readings, or check that the value is greater than 0x265, before performing the subtraction...
As a 'comment', read the ADC, in the timer loop, and gt rid of using the ADC interrupt. So:

kein · Joined: 23 Jul 2007 Posts: 103

Thanks Tlemah

kein · Joined: 23 Jul 2007 Posts: 103

Thanks Tlemah for ur help. I've incorporated the changes u made into my code and even made changes to my filter. The fact is the filter distort my signal. In my interrupt subroutine I've am reading a sinusoidal signal into a variable which is saved into a ring buffer in filter function. The sin(12.5*t) has a frequency of 2Hz. When i output/print out the unfiltered signal I get the correct sin wave and if i pass it through the filter, I get something similar to a noisy signal. What is the problem here? The filter coefficient from a lowpass filter whose cut-off frequency is 3Hz and coefficients are 16-bit integers.
Please help..

Code:

Ttelmah · Guest

You still have the _sign_ problem that I pointed out before.
This will completely distort the results.
You are now using a sin function in the interrupt to generate the psuedo value. This will return +1, to -1. So your value will be +1000 to -1000, which you are then putting into an int16, which is an _unsigned type_. The value will then be seen as +1000 to 0, and then jump to +65535, to 64536.
I pointed this out before....

Best Wishes

kein · Joined: 23 Jul 2007 Posts: 103

sorry I assumed int16 is signed by default . Yes indeed that solve some of my problem. The sin wave is perfect now however my filter output are really bad! Here are the changes made. Please help.
Kind regards,

Ttelmah · Guest

I would suspect you are overflowing the arithmetic in several places. If you 'sum' your filter terms, you get 45604. If the routine was called with all the entries equal at (say) +1000, and the arithmetic applied to this, the result would be 45604000. Even if you assume the 'average' value coming in is +500, the arithmetic would give 22802000. Have performed the addition, you put the result straight into a signed int16 variable (can hold 32767 max....).
However this won't happen, since the multiplication of the buffer value and the term, is being done using signed int16, and will overflow on the way. Your biggest term, is 0xF5C (3932), and times 1000, will give 3932000, over 100* too large for the arithmetic being used...
Also, declare your variables at the start of the function, not the block. Though C++, allows this, and CCS, supposedly supports this, the older 'C style' declarations are safer...

kein · Joined: 23 Jul 2007 Posts: 103

Dividing y by 65536 prevented the overflow indeed although the signal (sine wave) is still distorted making it look like a square wave. I've increased the number of division by factor of 8 and overflow is removed.

The filtered signal is sinusoidal just like the original sin wave but offsetted.
The offset doesn't seem normal to me! How can We prevents the offset
?

Ttelmah · Guest

Offset is normal.
The filter looks 'back in time' by 32 elements. The peak response is to the element 17 samples ago. Filters always introduce phase delays.

Now, If you are prepared to accept a slight loss of accuracy in your filter, and you want to do other things with the processor (currently the filter is using a _lot_ of the processor time), there are quite a few things you can change.
First, your 'simulation' (using the sin), is putting larger values into the buffer, than the real data. The ADC, only returns 0 to 1023. You subtract 0x266 (why this odd value? - if the input is symmetrical, you would normally expect the 'middle' value to be 0x200). With 0x266 subtracted, the 'real' values, can only be -614 to +409. If you can bring the signal to be symmetrical, and have -512 to +511, and then take your filter terms, and divide them by 64, you will 'lose' the some terms, and degrade the accuracy a little, but the multiplication, will then fit inside the signed int16 arithmetic. So the 'biggest' term, will be +511 * (0xF5C/64) = 511 * 62 = 31682. This will speed up the arithmetic a lot, and the loss of accuracy will be surprisingly small.
Now, your final result will need (presumably) to be scaled to some output range (DAC?.). If you can chose the terms, so that the final division, is a 'nice' value in binary terms (such as /256, /65536 etc.), this can be performed by taking the MSB's of the result, rather than an actual shift (or even worse a division...). However the saving from this is small (since this is only done once for each filter pass).
There is also a 'trick' you can do in the term array. If you make this _double the size_, with the whole array repeated a second time (so the elements go from 0 to 63), then you can avoid having to do any arithmetic on the index to the array. You do the maths like:

kein · Joined: 23 Jul 2007 Posts: 103

Just a quick question with regards to the filter coeffecient. When you say I double the size of the term array, did you mean double the size of coeffeicent array (h[2*size] or the ring buffer (ring[])?
Because below it seems you have increased or double the size of the coefficient array (h[]).

Ttelmah · Guest

Coefficient array.
The entries in this are the 'terms' calculated for the filter being used.
The 'point' is that when you have the ring array 'full', your 32 ring elements will correspond exactly to the elements in the coefficient array. Then when you add one more element to the ring, if you worked from the start of the ring buffer, you would want to use 'coefficient -1' as the coefficient for the first entry in the ring buffer, then use coefficient 0, for the next element, and so on. By having the buffer double the size, with the contents duplicated, you can operate through the data array, without having to use any offsets, just shifting where you start in the coefficient array.
In what you show, You also need to have the table contents duplicated. So:

kein · Joined: 23 Jul 2007 Posts: 103

Sorry for bothering you much but it does not work. The signal is worst and severly distorted.
Below is the code:

Guest · Posted: Thu Jul 03, 2008 4:53 am

Have you scaled the incoming test numbers or real values as I said?. This will _only_ work, with a maximum +511 to -512 range. Otherwise back to overflowing the maths.
You really should be doing the testing I described earlier. Stick the data into a simulator, or ICD, and look for each pass, at what the numbers actually 'do'.

Best Wishes