Shifty VU with FastLED FHT_Log - weird & random results

Hi, I recently bought the Macetech ShiftyVU so I can make my ws2812b led strip dance to the music. Works great when reading the serial input and triggering different animated effects when the volume increases beyond a given value.

But yesterday I loaded up Andrew Tuline's FHT_Log sketch (available here: which uses Fourier transforms to separate out frequencies in audio input. He has a great demo here showing how a strip reacts to a rising and falling sine wav:

But the strip is not performing as expected. I can feed in pure sine notes from my music software but I'm just getting weird random flickering lights instead of a specific portion of the leds lighting up. The lights respond a bit more to volume jumps, if I twist the volume knob up and down, but doesn't show anything even vaguely related to note pitch.

I don't understand the first thing about fourier tranforms or the fft/fht code. But Andrew's code is usually slick and reliable. I know my audio signal is good and strong because it works well with ordinary analogread input. I'd like to get some basic frequency analysis going (even just low notes/high notes) because interpreting music based solely on audio signal strength requires fine-tuning the input volume for different music tracks, otherwise you either get too much activity (triggering of the lights) or not enough.

Does anyone know if the Shifty VU somehow interferes or clashes with the FHT activity and prevents frequency detection from working?


I found a related FHT post here - - which offered the code below as a simple test tool:

  • #define LOG_OUT 1 // use the log output function
    #define FHT_N 128 // set to 128 point fht
    #include <FHT.h> // include the library

void setup() {
Serial.begin(9600); // use the serial port
void loop() {
for (int i = 0 ; i < FHT_N ; i++) { // save 128 samples
fht_input = analogRead(2); // put real data into bins

  • }*
  • fht_window(); // window the data for better frequency response*
  • fht_reorder(); // reorder the data before doing the fht*
  • fht_run(); // process the data in the fht*
  • fht_mag_log(); // take the output of the fht*
  • for (byte i = 0 ; i < FHT_N/2 ; i++) {*
    Serial.print(" ");_
    *_ <em>*That produced readable output that changed when I fed in audio ( a few seconds of a dance track). Attached is a small text file showing the change when audio is fed in - so its definitely doing something!*</em> _*_
    fht_log_out.txt (8 KB)*

Ok I’ve been using serial.print to display the value I’m getting out of the FHT_Log script.
There are four processing stages that FHT runs through to ‘transform’ the raw data: Windowed, Reordered, FHT_Run and FHT_Mag_Log:

fht_window(); // Window the data for better frequency response.
fht_reorder(); // Reorder the data before doing the fht.
fht_run(); // Process the data in the fht.

These functions are described here: FHTFunctions - Open Music Labs Wiki
I added serial.print commands to these stages. I then generated a very fast sine wave in music software and captured each stage of 256 ‘samples’ from the raw analogread input to the final output. Then I made an excel graph (it’s ugly but it shows what’s going on. Image also attached.)

Not sure that’s displaying - url here: Imagebin - Somewhere to Store Random Things

The darker blue line is the raw data, recognisably a small section of a very fast sine wave.
The red line is after the windowing - quite a radical change but you can kind of see a relationship.
Green line is Reordering - no similarity to the raw data as far as I can see
FHT_Run (purple) is virtually the same as FHT_mag_log (pale blue). neither bear any relation to the raw data.

The final output of this process is fht_log_out - which I assume is the final FHT_mag_log output? That’s then used in the “void fhtsound” section of the script to draw the leds.

Either I’m completely barking up the wrong tree (quite possible!) or FHT_Log is mangling my data beyond all recognition. Are there some tweaks I should be doing to the initial settings to improve performance, maybe?


Most likely, you are allowing audio frequencies higher than 4.8 kHz (one half of the ADC sample frequency) to reach the ADC input.

Look up “FFT aliasing” and “sampling theorem” to see why you will get what appears to be nonsense if this happens. Keep in mind that a generated sine wave is likely not to be pure, and contain higher frequencies than the fundamental.

A steep low pass filter on the input, with a cutoff of half the sampling frequency, is required.

Thanks fr your reply jremington, but not sure I’m interpreting you right :confused:

I tried again and added both a low pass and a high-pass filter in my music software (Ableton Live), which restricted the audio input to >100hz and <1khz. I then created a sweeping sine moving about two octaves within that range. But still same results. Image of filter setup here:

The final fht_mag_log data that’s coming out is still hovering around between -4 > 0, which is very tiny and doesn’t seem to relate to the input in any way. And the leds aren’t lighting up to represent the frequency changes :frowning:

Either way for this to be usable I need to be able to feed music mp3s in easily, without having to pre-EQ it. If it can’t take a fairly pure narrow-band sine wave then something else must be wrong.

Image link: Filters

but not sure I'm interpreting you right

Don't take my word for it. Look up FFT aliasing and the sampling theorem. These topics are extremely important to understand. If you don't, you will get nowhere.

Please post a schematic diagram (not Fritzing) of the analog input circuitry.

If the input signal is outside the range of 0-5V on an analog input, the FFT/FHT will also produce nonsense.

Thanks for your input jremington. I got around the problem altogether by buying the Sparkfun Spectrum shield and doing frequency analysis in the hardware rather than software.