Digital Filter implemented on AVR

[DanioIO]

Hi,
I am trying to implement a digital notch filter on Atmega8. The whole project is about getting data from ADC and filtering it out and then send via Bluetooth. Im designing filters using MATLAB build in functions like fir1, butter, elliptic etc. I would like to operate using floats on AVR, but using simple cast from double (generated by MATLAB) to float results in a filter that isnt stabled (I test it only in Simulink). Can i cast my filter coefficient to float without losing stability?

Or maybe i should use a DSP, can anyone suggest a very cheap one and in a small package like Atmega8 or smaller. (i need only I2C and UART).

[jahonen]

Sounds like you are having problems with numerical precision if converting to float makes the filter unstable. Can you tell what is your sampling frequency and specifications of your filter? Are you using direct form filter with filters of order > 2? If so, split the transfer function to several second order sections and try again. High-order direct forms are pretty much doomed to fail, excluding some special cases.

FIR filters are always stable regardless of the numerical precision but response shape might get distorted as the quantization becomes coarser.

Regards,
Janne

[T3sl4co1l]

Also, what kind of speed are you expecting?  Don't expect anything over 10kSa/s for integer data in small to moderate filter lengths; maybe more like 100Sa/s (i.e., 100 times slower) for floats.  Proportionally less for proportionally longer filters (required if you want a deep, sharp notch).

Otherwise, there's these things called op-amps...

Tim

[Jeroen3]

Use fixed point math, as in http://en.wikipedia.org/wiki/Q_(number_format)

[nctnico]

The last time I used the filter design tool from Matlab it could export the coefficients to a C header file. The ancient version I used only allowed to use even numbers for quantisation (14:16) for 14 bit coefficients and had several other quirks. Furthermore the input signal needs scaling. This factor is given with the coefficients in the result window; not in the C header file. Fixed point math is the way to go here.

[dannyf]

Use fixed point math instead. You can find the code pieces online.

for proven implementation, try arm dsp lib, implemented in the latest cmsis.

it is fairly easy to port it to avr.

[mrflibble]

As has been suggested, fixed point math is the way to go. Also, depending on your required data rate you might want to take a look at arm microcontrollers that have single cycle multiply-accumulate instructions.

[hamster_nz]

The better way around would be to evaluate the performance of the hardware first (i.e. how many MACs you can acheive) then use that to deciede what sort of filter you can use. It may be that you just don't have enough grunt to acheive what you want.

If your IIR filter is unstable then it might be that you are pushing it too hard - all sharp IIR filters are only really suited to long floating point,with careful analysis of possilble rounding issues. You might be able to filter twice with a less sharp filter.

Depending on your needs, see if you can get away with a moving average LP and HP filter to make your bandpass. It is really cheap and easy to implement.

Mike

[f5r5e5d]

iir biquad have often unsuspectedly large accumulator word length requirements - one scales as the square of fs/fc

floating point really doesn't do the job - I needed 48 bit accumulators in a project that output 16 bit data

[hamster_nz]

iir biquad have often unsuspectedly large accumulator word length requirements - one scales as the square of fs/fc

floating point really doesn't do the job - I needed 48 bit accumulators in a project that output 16 bit data

Sounds like the perfect application for the Xilinx FPGA's DSP48 blocks (18-bit x 25 bit with 48 bit accumulator), and can run at over hundreds of MegaMACS - not very well suited to an AVR at all.

Just saying!

[T3sl4co1l]

Well, I'd guess if you only needed ~100Hz sample rate, you'd have more than enough from an AVR with that kind of load... but anything a little peppier, well..

[mrflibble]

Sounds like the perfect application for the Xilinx FPGA's DSP48 blocks (18-bit x 25 bit with 48 bit accumulator), and can run at over hundreds of MegaMACS - not very well suited to an AVR at all.

AVR: could do the job for the OP, if it's not too demanding.
STM32F4: lots more headroom. Single cycle 64-bit multiply-accumulate (as in 32X32 + 64 = 64) at 192 MHz.
Spartan6: no contest whatsoever. Pipelined dsp48 blocks are nice.

I recently implemented a 5th order delta sigma modulator on both stm32f4 and spartan6. The stm32 does manage a decent clock rate, but nowhere near that of the fpga. FPGA: 200+ MHz? No problem. And loads of resources to spare. But then again the development effort for fpga implementations (vs mcu) tends to be a bit higher.

Anyways, it would help if the OP could tell us some performance requirements.