Getting back into the hobby...got some more learning to do! Starting back with RGB

eagletalontim

Been quite some time since I have posted here and now I am quite rusty! Not sure what all has changed, but I had some old PCB's with the Prop soldered to them and started dabbling with SPIN code again. Never could grasp Assembly

A worker of mine is interested in doing an RGB or ARGB sound activated controller. After doing a bit of research, I have located an interesting IC...the MSGEQ7 which apparently is an amazing IC and can easily split the spectrum of an audio signal to 7 different spectrums. I really don't need all 7, but hey, if they are offered, why not use them. We would like to have the RGB change color based on the spectrum, not volume.

https://www.sparkfun.com/datasheets/Components/General/MSGEQ7.pdf

Problem I have is properly communicating with the MSGEQ7 from the Prop. I really suck at fully understanding datasheets and putting the information in them to proper use. I can see there are 2 pins that are Reset and Strobe which I believe are the signal needed from the Prop to get data out from the MSGEQ7.

So from what I gather is I need to do something like? :

CON
        _clkmode = xtal1 + pll16x                                               'Standard clock mode * crystal frequency = 80 MHz
        _xinfreq = 5_000_000

OBJ
  Pst    : "Parallax Serial Terminal"  ' to be used for testing
  adc : "adc0831_fast"

VAR
  LONG adcArray[6]      ' Array to hold spectrum data from ADC
  BYTE i

PUB main
  dira[reset_pin]~~      ' set to output
  dira[strobe_pin]~~    ' set to output
  outa[reset_pin] := 0  ' ensure pin is off
  outa[strobe_pin] := 0  ' ensure pin is off

  adc.start(cs, clk, data, sample_rate, @adcValue)
  pause(10)    '  Let ADC initialize

  ' initialize MSGEQ7
  outa[reset_pin] := 1
  outa[strobe_pin] := 1
  pause(2)
  outa[strobe_pin] := 0
  pause(2)
  outa[reset_pin] := 0

  i := 0
  repeat
    outa[strobe_pin] := 1
    pause(2)
    outa[strobe_pin] := 0
    pause(2)    '  allow time for ADC to update?
    adcArray[i] := adcValue
    pause(2)
    i++
    if i == 7  ' array 0 to 6 for 7 spectrum data
      i := 0

So none of this code is tested at all since I have not bought the MSGEQ7 just yet. This is off the top of my head :P Maybe there is a better option out there for what I am trying to do I seen another project using the same IC, but there is no code to go by.

kwinn

That's an interesting chip to play with. The code you have so far seems reasonable for controlling the chip and converting the outputs to digital. Now you need to come up with a plan to convert those readings to intensity values for the RGB leds. Do keep in mind that the output readings are going to be proportional to the volume (voltage) of each part of the spectrum so if you use those values to control the intensities of the RGB leds the intensity of the individual R, G, or B leds will vary with the voltage from that frequency band, and the resulting color will vary with the ratio between those voltages.

eagletalontim

I was reading that too which is going to be another interesting problem to over come as the input level will more than likely be adjusted. Not sure if I can do a software filter or if I need to use some sort of other hardware method to avoid this issue. My thoughts are to adjust the input filtering on Pin 5 (IN) to Peak the ADC value (255) with the volume at the highest listening level, then use software to get the average of all 7 of the spectrum values or use the Peak signal to display the RGB color.

BYTE rgbColor
BYTE R_intensity
BYTE G_intensity
BYTE B_intensity

PUB getAverage(the_array, sample_count) | i, arraysum  ' May not use this function
    arraysum := 0
    repeat i from 0 to sample_count
      arraysum += long[the_array][i]
    return arraysum / sample_count

PUB getPeak(the_array, sample_count) | i, peak    ' get most dominant spectrum.
    arraysum := 0
    peak := 0
    repeat i from 0 to sample_count
      if peak =< long[the_array][i]
        peak := long[the_array][i]
    return i  ' may also use peak instead of i

PUB calculateRGB | peak, peak_val, addto, i
  peak := getPeak(@adcValue, 7)
  peak_val := long[@adcValue][peak]  ' not sure if this line would work
  addto := 255 - peak_val  ' figure amount to add to other values to increase Volume.  This might cause problems...

  repeat i from 0 to 2  ' R - G - B
    case i
      0:
        IF peak == 0 OR peak == 1
          R_intensity := long[@adcValue][peak] + addto
        ELSE
          R_intensity := long[@adcValue][0] + addto   ' default if not peaking in this range
      1:
        IF peak == 2 OR peak == 3 OR peak == 4
          G_intensity := long[@adcValue][peak] + addto
        ELSE
          G_intensity := long[@adcValue][3] + addto   ' default if not peaking in this range
      2:
        IF peak == 5 OR peak == 6
          B_intensity := long[@adcValue][peak] + addto
        ELSE
          B_intensity := long[@adcValue][6] + addto   ' default if not peaking in this range

This code has not been tested either, but should represent the idea. If the "peak" is in the low range, Red will light up more intense than the rest of the ranges.

kwinn

eagletalontim wrote: »

...... If the "peak" is in the low range, Red will light up more intense than the rest of the ranges.

My guess is that the average peak value for each of the 7 bands will vary quite a bit, so getting a nice display may not be so easy, but since it can be done with code instead of hardware you can do a lot of experimenting. Using an array of 2811/2812 led strips with the right software would make for an awesome display. Imagine using some of the bands for color and one or two for shapes or led addressing on an xy array of leds.

eagletalontim

So for an update... Got the MSGEQ7 chips in and got it all working Also have a 16ft ARGB strip dancing to the music, but I have a slight dilemma on processing speed for a really long strip... 500 + LEDs.

Thanks to JonnyMac's code in the obex, I was able to get the strip working well with 150 LED's, but if I stretch out further, my array shift slows everything way down. The array shift is to give the appearance of the LED's traveling down to the end.

Here is the bit of code that is slowing everything down...

PUB Showem | i
    repeat
      repeat i from STRIP_LEN to 1  ' <<<<<  This is SUPER slow if STRIP_LEN is set above 500.
        pixbuf1[i] := pixbuf1[i - 1]
        
      strip.use(@pixbuf1, STRIP_LEN, LEDS, PIX_BITS)
      time.pause(0)

Is it possible to speed this up? I could not figure how to simply shift each value in an array up one and the last one "fall off"

JonnyMac

What, specifically, are you trying to accomplish? On a project I did last year I had a situation that required a crawling rainbow. Creating this effect on-the-fly was very slow, so I ended up pre-calculating the buffer with extra segments. When the program runs I simply manipulate the start-of-buffer pointer to create the effect.

eagletalontim

The "Showem" is running in it's own COG which takes the pixbuf1 array and shifts each value up one to the next index, then when that is complete, display it to the LED strip.

pixbuf1[0] is updated from the calculated value of the spectrum from the MSGEQ7 which is done in the "Main" loop.

If the strip is 150 LED's long, it is quick and displays correctly even if I add a 25ms delay in the "time.pause". If I change STRIP_LEN to 600 LED's, the display of the LED's "running" down the strip slows WAY down. This leads me to believe the first part that shifts each index value up to the next index in pixbuf1 is what slows this down quite a bit.

I was thinking I would probably need to make another COG run that will just update the array, but that seems like a waste of a cog if there is another way to do this.

JonnyMac

I did a quick test and I think longmove() will work for you. Try this:

  longmove(@pixbuf[1], @pixbuf[0], STRIP_LEN-1)

This is the code I used to test.

dat

  buffer        long    0
                long    1
                long    2
                long    3
                long    4 { end of buffer }

                long    0


pub main | idx                                                         
                                                                 
  setup                                                          
                                                                 
  term.rxflush
  term.rx                                                        
  term.tx(term#CLS)                                              

  longmove(@buffer[1], @buffer[0], 4)

  repeat idx from 0 to 5
    term.dec(buffer[idx])
    term.tx(13)

The output is:

0
0
1
2
3
0 <-- this value is after buffer

Mark_T

Rather than shift the entries in the buffer, move a pointer into the buffer? You'd need to extend the buffer
and handle wrapping, but the cost of "shifting" goes away.

eagletalontim

Got a pretty nice display working . Thank you JonnyMac for the last bit of code. That worked perfectly!


https://youtu.be/16sXoIh-F2Q

Jeff Haas

Wow, very nice. How many leds did you eventually end up driving? And can you share the code? It would be interesting to see.

eagletalontim

I am currently driving 600 total, but am driving them down the middle of the chain to give the "burst" effect. I will have to post the code later as I am on my phone right now. Got to clean some of it up too... Lol. It has been a long time since I have coded in SPIN.....