Hi Frank Thanks for taking the time to answer. I believe that when I did what you have suggested, I didnt get the colours I wanted because of the hue calculations. I have now managed to simplify the code completely by taking out the hsi2rgbw libraries and including simple calls to the pwm led routines for red green and blue - I now set the hue array values to the amplitude values and set the r g and b pwm values to the first 3. That is now working, except for a strange problem that the LED only works if the processor is sending serial data to the host - I have now got it continually sending some useless text to keep the led lit! BTW, I can get away with no mic preamp by setting the lower signal to 20dB. Thanks again Tony ps there is nothing wrong with the comments in the code and you have documented it very well - its just that I am not a very competent programmer, and trying to use this example for a simple course I am running for some Arduino lovers! So I wanted to keep the LED driving as simple as possible, even though the number crunching going on in the fft is complex (sic).

Quite strange you need to keep the serial port busy in order to drive the leds. Did you put the led code in the serial function? If possible, publish your code, we can have a look at it and help to improve it.

Hi Frank I have published my code here: http://mbed.org/users/tony1tf/code/KL25Z_FFT_Demo_tony/ As far as I can see, the LED driving should be independent of the serial port. Currently the code continually writes "this will make it work " to the serial port and the LED works OK. If you comment out that code at line 371 you will see that the LED stays off, unless you request some data on the serial port. I have added a request command for the 3 "hues" - the R G and B values (0 to 1) - "GET HUES;"

I had a quick look at your code (haven't had time to run it). I think the problem is that the code runs too fast, that's why the printf you added makes it work (not only it slows down the while loop but you also steal time from the FFT conversion - will result in incorrect conversions). You should be able to get the same result by raising the SLOWDOWN value (note that this value is a cpu-clock dependent counter). As this is non-blocking, it won't interfere with the FFT conversion.

I assume you didn't remove the hues spreading code in spectrumSetup() when you tried using PIXEL_COUNT = 3?

Hi Frank SLOWDOWN doesn't appear to do anything. I did try removing the hue spreading code in your original code, but the whole thing is too complex for me to understand and remove unwanted parts, which is why I simplified the code. I have been experimenting and found that there are places where I can't get printf to do anything (for instance I wanted to echo anything typed, or the whole command when the ";" was detected - have now added a flag to turn printing something on or off in the main loop rather than modifying the code each time - that does work and allow the LED to light. Clearly, I dont quite understand how the various parts of the code work.

Hi again Added a simple 10ms wait before "restart audio sampling". Now the simplified code works well, and seems a lot more sensitive. I will have to learn why the sampling and fft code is affected by this.

Mystery solved : We need to raise the FFT_SIZE. Due to memory constraints, i had to keep the FFT_SIZE low as i was using a high PIXEL_COUNT. Setting both PIXEL_COUNT and FFT_SIZE to a low value results in erroneous output. Using following settings in my original code works very well : SLOWDOWN = 10 - SAMPLE_RATE_HZ = 40000 - SPECTRUM_MIN_DB = 30.0 - SPECTRUM_MAX_DB = 80.0 - LEDS_ENABLED = 1 - FFT_SIZE = 128 - PIXEL_COUNT = 4 - MAX_CHARS = 65

Notice that PIXEL_COUNT is set to 4 instead of 3 (the hues spreading calculation in spectrumSetup() subtracts 1 from PIXEL_COUNT) and SAMPLE_RATE_HZ = 40000 (sample rate needs to be twice the frequency, so for 20kHz, we need to sample at 40kHz). To confirm we really get RED, GREEN an BLUE, change SLOWDOWN to 1000, 1001 and 1002.

Hi Frank Thanks for the additional info. I have gone back to your original code using these parameters, and have 2 problems. Firstly, there has been an update to mbed and I get the following error: Error: Symbol NMI_Handler multiply defined (by mbed_overrides.o and main.cpp.KL25Z.o). I got rid of this by deleting the 3 lines: extern "C" void NMI_Handler() { DigitalIn test(PTA4); }

Not sure whether doing this has a knock on effect, since I am still having problems - with sound input the LED just cycles through the 3 colours - brightly if I put my finger on the input - I dont get a colour corresponding to a frequency. I have checked that SLOWDOWN of 1000, 1001 and 1002 gives the 3 separate colours. The code certainly doesn't seem to work like my simplified code. I'll carry on experimenting and see if I can understand it - I have added commands to view hues and frequency bands like in my previous code. The hues command gives 0, 120, 240, 360 irrespective of the input. Tony

You are right, the NMI handler needs to be removed as the latest mbed libs change the NMI input to a plain DigitalIn (https://github.com/mbedmicro/mbed/blob/master/libraries/mbed/targets/hal/TARGET_Freescale/TARGET_KLXX/TARGET_KL25Z/mbed_overrides.c).

The color cycling is because i set SLOWDOWN=10. This is similar to the 10ms delay you introduced in your main loop but, as i mentioned before, your delay is blocking while SLOWDOWN is non-blocking. This means that, every time you add code/calls to your main loop, you'll probably need to update the delay as well. Not that it's very important in this application, but, whenever possible, it's good practice to avoid blocking delays. As SLOWDOWN behaves differently from your ms delay (SLOWDOWN shows each color a little longer), you could use a 10ms timer in your program to call samplingBegin(). As a result, the main loop will not be blocked = lots of additional time to do other stuff.

Quite strange the hues command returns these fixed values.