Teensy 3.1 and ADC + FIR Filtering

Status
Not open for further replies.
K

knuffiandy

New member
Hi,

iam new at teensy and in general in DSP.

I want to create a low pass FIR filter with a corner frequency at 100 khz. I calculated the filter with SCILAB and i have the correct bode curve and filter coefficients. In general i know the existing CMSIS lib. from ARM for Cortex-M4 processors.

A signal which should injected to the AD converter should be sampled and filtered with the DSP engine of Teensy.

My question is now if the AD converter is able to convert the signal without aliasing and could calculate the filter output without speed problems for continious application.

I dont know how to get a feeling or to calculate the max. possibilities for sampling and filtering of signals of teensy and for the max. MIPS of Teensy and for which application i need how many MIPS.

I know that the sampling rate must more as 2 x max. signal frequency of the analog signal.

cheers,
Andy
 
I've personally only done this stuff at 44 kHz sampling, in the audio library. Everything I'm going to write in this message is in terms of the audio library, and the possibility of (maybe) scaling it up to higher frequencies.

The AudioInputAnalog object configures the ADC for averaging 8, on line 48:

https://github.com/PaulStoffregen/Audio/blob/master/input_adc.cpp#L48

Perhaps there's hope for achieving 353 kHz sampling rate, if this is changed to 1, and lots of other stuff is changed too. I really haven't done any testing to determine how much higher the sample rate might be able to go. The ADC does have faster, lower-res modes, so it might be possible to get the sample rate up more.... maybe.

Assuming 350 kHz sampling, that's a nyquist bandwidth of 175 kHz.

Since your goal is a 100 kHz low-pass filter, unless the stuff you're trying to filter away exists only within the 100 to 175 kHz range, the whole system will be pretty useless.

But perhaps if you have some very special application, like a modulated signal that's known to be in that narrow range, or perhaps if this is an academic project where you only need to show results with fairly artificial signals, then maybe this could work?

I believe the input DMA code could probably run 8X faster. But that's never been tested, so really, that's just a guess.

Regarding the CPU requirements for the FIR filter, the one published benchmark is here:

http://www.pjrc.com/teensy/gui/?info=AudioFilterFIR

If a 100 tap filter consumes 9% CPU time running at 44 kHz sample rate, you can be pretty confident it'll scale up to 72% if run 8X faster.

Without having tested such speeds myself, nor anyone else sharing any info so far, that's my best guess. You might be able to scale the ADC up to about 350 kHz, and maybe beyond that if you use the lower res modes. If you do, the FIR filter will use nearly all the CPU time with about 100 taps. If your impulse response is much shorter (you didn't mention how long your filter's response needs to be), you might have some chance of making this work within the CPU power, but if you need a lot more taps and especially if you increase the sample rate further which also means more taps for the same impulse response, you'll run out of CPU power pretty quickly.

That's the best info I can give. If you do attempt this, and especially if you manage to get stuff working at much higher sample rates, I hope you'll share your results or at least post some general info about what did and didn't work.
 
You might also be able to overclock Teensy 3.1. There's 3 more overclocking options, commented out, within boards.txt. Many people have reported success, at least running at room temperature, using 144 MHz. That's give you a little more CPU power to work with.

But if you've got stuff well over 200 kHz in your analog signal (the reason for the low-pass filter), or if you need a long impulse response, then you're going to require much higher performance hardware than Teensy 3.1.
 
knuffiandy said:
A signal which should injected to the AD converter should be sampled and filtered with the DSP engine of Teensy.

My question is now if the AD converter is able to convert the signal without aliasing and could calculate the filter output without speed problems for continious application.
Click to expand...

Which ADC?
The one on the Teensy? NO, this one is a 16 bit SAR ADC that requires an analogue anti aliasing filter.

the one on Paul's audio adapter uses a SGTL5000, that samples up to 96 kHz and most likely is a sigma delta ADC that requires no anti aliasing filter, as long there are no frequencies that are much higher than 96 kHz.

I have not seen 16+bit sigma delta ADCs that are capable of a 100+ kHz 3dB-bandwidth.
E.g., the cirrus CS5361 can handle 192 kHz sampling but has a bandwidth of 48 kHz, with a 'poor' transition band characteristic.

All 16+bit 200+kHz sampling ADCs, that I know, are SAR ADCs and require anti-aliasing filters.
 
WMXZ:

ok. if i understand you correctly the SAR ADC of the teensy is able to sample + convert a physical 100khz signal with an anti-aliasing hardware low-pass filter and when scaling up the sample frequency oft the Teensy AD to 350 khz like Paul wrotes ?

Paul:

how is it possible to calculate / guess the CPU load for which amount of taps in the filter on which sample rate ?
 
knuffiandy said:
how is it possible to calculate / guess the CPU load for which amount of taps in the filter on which sample rate ?
Click to expand...

Two assumptions are required:

#1 - CPU usage scales linearly with the number of taps. Each tap requires reading data + coefficient, and a multiply-accumulate.

#2 - CPU usage scales linearly with the sample rate. If you double the sample rate, you're simply doing the same math twice as often, so the CPU usage doubles.

These assumptions may not be perfectly true. There's probably some fixed FIR filter overhead that becomes a factor for small numbers of taps. Likewise, there's probably some fixed overhead with I/O. But let's ignore such minor details.

Since we know 100 taps at 44 kHz consumes 9% CPU, you can scale it to 350 kHz by simply multiplying by 7.94 (350 / 44.1), for 71% CPU usage at 350 kHz.
 
ok. I think i have 80 khz of max. physical signal input. So i need a ADC sampling rate of 160 khz (Nyquist-theorem without oversampling). So i have a CPU load of about 9% * 3,6 = 32% at 100 taps. So continious sampling and fir filtering should be possible with the teensy if i put a lowpass anti aliasing filter ( which order ? which attenuation at 3 db on which frequency) in front of the ADC of the teensy ?
 
The particular performance you need from your filter depends on the 'bad' signals that are present above 80 kHz, and the accuracy you want from your ADC output.

The reason you need an anti-aliasing (AA) filter, is that if you sample at (say) 160 kHz, signals at 80k+x become indistinguishable from those at 80k-x. Thus a 90 kHz input signal (that gets through the AA filter) will be indistinguishable from a genuine 70 kHz signal. The filter performance you need depends on the accuracy you need the 'good' signals to be converted at (basically how much amplitude error you can live with), and the level of the possible interfering signals. This in turn depends on your application needs...

Very approximately: for instance, if you want 8 bit 'accuracy' (signal-to-noise ratio), this means errors of ~ 1/256, so a full scale 81 kHz interfering ('bad') signal needs to be attenuated by a factor of 256, while, if you want to simultaneously digitize 'good' 79 kHz signals accurately 9error of 1/256 ?), you need the filter to attenuate by no more than 255/256. This is a very sharp filter, and is physically impractical.
 
100 kHz is indeed a pretty fast sampling rate. Like Paul, I've been focusing on the Teensy for Audio processing, where my intention is to use sample rates in the 40 kHz neighborhood.

I did, however, do a bunch of benchmark tests using a Naive C implementation of an FIR filter so that I could do the testing on a variety of platforms (Arduino, Maple, Teensy, etc). If I were to use the DSP extensions, my results should get faster (I have used them for FFT processing and they're good for about 50% more speed).

If you're interested in my FIR speed results (both Int and Float), you can check out my write-up at the link below. I do a variety of different FIR filter lengths and I do both Ints and Floats. I even show results for a K66 board, which should give similar performance as the soon-to-be-released Teensy 3.6!

https://openaudio.blogspot.com/2016/09/benchmarking-fir-filtering.html

Chip
 
Status
Not open for further replies.
Back
Top