Code causes arduino to not work at all

Ok so then the problem is that the 4000 int is at the very limits of memory, so that setup works when the code in the main loop is not included, but when it is, setup gets overwritten by the large array?

I'll try halving the array size.

No, it is not at the very limits, it is way beyond the limits, and halfway through the next county.
What board are you using?
Even halving will be too much for many boards.

Duemilanove with atmega328.

Time to do the math(s):
328 has 2048 bytes of RAM.
A 500 element int array should be safe.
But certainly not 2000.

A 500 element int array should be safe.

The safeness of a 500 element int array depends on what other variables, constant strings, and stack needs you have.

In the code you initially posted, it would seem that 500 is a safe size.

OK, that was not very clear when I bought it, I thought the MCU did everything in the 30kB space. So the 32kB is for the program only and 2kB is RAM?

I can lower the sample size, but for every halving of sample size, I loose one of the lower central frequencies; from my understanding. So for a 500 element array I will loose 32,64 and 120Hz, I can drop the sample size down even more, but for every lost central frequency, I have to filter the audio signal using an op amp and directly feed the frequency into one of the analog pins and use the bargraph example code to output it on the matrix.

With hmm 6 analog inputs I can get rid of 32,64,125,250,500 and 1000Hz... so that's a sample size of 125 approximately.

If the arduino had 10 inputs I could do this fully by using filters and not need to do the fourier transform.

With hmm 6 analog inputs

...but only one analogue converter.

OK, that was not very clear when I bought it, I thought the MCU did everything in the 30kB space. So the 32kB is for the program only and 2kB is RAM?

Yes, read up on the difference between Harvard Vs Von Neumann CPU design. All AVR processors are of the Harvard type, using separate program and data memories. You PC is using a Von Neumann type processor where program and data share the same memory.

Lefty

...but only one analogue converter.

Can you clarify on that? You mean the mcu can only read one analog pin at a time? Isn't that evident from the programming, ie it can only execute one command at a time?

The six inputs have an analogue mux behind them, feeding a single ADC.
If you want to use all six inputs, the sample rate on any one input will be 1/6th what you woukd get if you stuck to a single input.
'one command at a time' doesn't enter into the problem here - a conversion takes about the time you could execute over 150 'commands'.

For what you want, I think some sort of DSP with parallel analog converters would be best. Of course, it depends on how far in the frequency domain you want to go and also at what accuracy.

You have a 10 bit "analog" signal and you'll be using integer math with the 16 bits on an 8 bit machine. This will make it, although faster than using floating point, slower than ideal. But again, this all depends on the frequencies you want to work with and the desired accuracy.

There's a link to a 8-bit FFT library somewhere in the forum that may also be interesting for what you want.
Also, if you want to perform a FFT on 6 signals at the same time, that will further reduce the sampling interval that you can use. Since you need to assure that sample takes place at correct intervals, you'll need to calculate how long the AD takes to sample. Then multiply the number of channels you're using and that will be the lowest sample time you can use.

Yes but the mcu operates at 16MHz, 150 commands should be nothing in comparison to sound frequencies, especially low frequency ones like 120Hz, as long as I can sample at maybe 4 times the specific central frequency, I should be okay I think.

For what you want, I think some sort of DSP with parallel analog converters would be best. Of course, it depends on how far in the frequency domain you want to go and also at what accuracy.

You have a 10 bit "analog" signal and you'll be using integer math with the 16 bits on an 8 bit machine. This will make it, although faster than using floating point, slower than ideal. But again, this all depends on the frequencies you want to work with and the desired accuracy.

There's a link to a 8-bit FFT library somewhere in the forum that may also be interesting for what you want.
Also, if you want to perform a FFT on 6 signals at the same time, that will further reduce the sampling interval that you can use. Since you need to assure that sample takes place at correct intervals, you'll need to calculate how long the AD takes to sample. Then multiply the number of channels you're using and that will be the lowest sample time you can use.

No you misunderstood, I'm not going to be performing FFT on the filtered signals, those one's are already broken down into one specific range of frequencies around each central frequency. I'm going to just map the voltage reading to 10 leds and directly output it.

I also forogot that one analog input needs to be used for the unfiltered signal so that leaves 5 inputs for filtered frequencies and a 250 integer sample.

I could also maybe do away with the filters and not need a 4000 point sample if I keep the magnitudes calculated from the last sample in memory and just add them to the magnitudes calculated from the current sample and then output them... hmm I need to think more about this.

Can you revisit your algorithm? Do you have to read and buffer 4000 integers in memory before you can process anything at all? You generally only need a buffer if the algorithm is structured so that it must go back over earlier samples and cannot be rewritten to do otherwise. If you can make it operate on the stream as it flows through then your need for a buffer goes away.

The fourier transform requires a sample of a signal to work or to 'detect' the presence of a frequency, in mathematics the signal would be infinitely long in time, but that doesn't work in real life, so a sample is required. The length of the sample depends on what frequency you want to capture and the length of time between each sample. Here the time difference is 8 microseconds between samples, with 4000 samples, assuming that each line of code is executed nearly instantaneously, that adds up to 1/31.25 of a second... or rather if there was a frequency component of the signal at 31.25Hz, you have a chance at capturing one wavelength in the sample.

Some bad things about this method is that the higher the frequency component that you're trying to find, the lower the resolution of the signal will be as long as you keep the same number of samples and keep the length of the sample long enough to capture the same bottom frequency. For example I am attempting to capture at the high end 16kHz which is near the hearing limit for most people. The period of a 16kHz frequency is 62.5 microseconds; at 8 microseconds between each sample you end up with 7 points representing a signal made up of supposedly infinite points. Ie you reduce a smooth signal into a series of square waves.

So you see my problem, the time between samples has to be short enough to adequately sample the highest frequency: 16kHz and the total number of samples has to be enough so that it covers a length of time long enough to capture one wavelength of the lowest frequency 32Hz... this is from my understanding of the fourier transform.

But I am thinking about that, as the fourier transform is an integral, I could just keep the sum of results for a short buffer and add them over cycles and totally clear them after a certain number of cycles, this should still be mathematically valid I think.

How are you going to manage 8us between samples with a 10kHz sample rate?

10kHz sample rate? Where are you getting this number from?

Wouldn't an IIR filterbank be a better algorithm for this than an FFT? The FFT would waste time calculating many frequency bands you don't need. The FFT needs a sample block to work on and needs a big output buffer, but a filterbank works on one sample at a time and just needs to store a few words of data for each band. Is there a particular reason your algorithm has to be an FFT?

Also I think you have to adjust the ADC prescaler to get it to work at audio speeds. I seem to remember by default the arduino software sets it to accurate-but-slow operation, probably too slow for audio.

10kHz sample rate? Where are you getting this number from?

The AVR datasheet.
Where are you getting the 125kHz number from?

Maybe Goertzel would be a better choice for you.

It's rougly 8 times the 16kHz frequency for the high end of the audible limit giving you around 8 samples per wavelength at 16kHz. (it's supposed to be 7.8us but supposedly the arduino can't do that)

I didn't know that the ADC can only do up to 10kHz.