*super late 3-year bump* I'm debugging this system at last, and I'm starting from the audio preconditioning hardware. This should DC block and add a DC bias of about 2.5V. My Arduino reads the output as a constant 1023/1023 == 5V. Hooking the audio output directly to the Arduino gives me a value fluctuating from 0/1023 to 100/1023. I've also checked that I definitely have 5.0V from ground to the 5V supply rail and that the audio input's common is connected to the Arduino's ground. Does anyone see any obvious mistake that I've made?



Edit: Turns out that AREF != VCC on the Arduino board, which I was not expecting at all. Now it idles at ~511, and audio makes the values swing towards the extremes of 0 and 1023. Debugging continues.

Edit #2: Debugged throughout the post-FFT postprocessing that generates (eventually) seven amplitude levels from the FFT output, as well as an estimation of beat based on low-frequency amplitude. As you can see from the below video, I need to switch from a linear to a logarithmic scale for discretizing the moving average of the amplitudes.

Would you mind posting the code you used on the arduino? I learn better by dissecting code than out of a book. Thanks.

I need to work on the beat-detection algorithm some more; I'll probably do that tonight. When I do get that working to my satisfaction, I'll send along my code for your perusal.

Thanks. I was wondering if there is any perminant memory on the arduino, or if it is all ram. I was thinking about using pre-programmed lighting sequences on the arduino, then taking a list which would put them in a specific order from the calc. If there is some memory on there, you could automatically load a previously stored list to run. If not, you could just program a random sequence for if there was not a calculator connected.

There is both EEPROM and RAM, but you're better off either baking the sequences into the program or sending them from the calculator each time you start the calculator program. The Arduino has about 2KB of RAM and something like 128 or 256 bytes of EEPROM iirc.

Note to self: If current beat-detection attempts aren't working well, look into http://www.gamedev.net/page/resources/_/technical/math-and-physics/beat-detection-algorithms-r1952 .

*bump* Fixed up the wiring on my insanely messy PartyMode prototyping board, replaced a TIP120 Darlington BJT that got physically blown apart from an accidental brush with 120V, and played around with my FFT a little bit. My full-scale prototype freezes when it enters a PWM mode, while a simple Arduino board does not. Any suggestions on how I could debug that?

Kinda wish I looked at that more whilst I was there with you. Feel I missed out on a nice hardware debugging session

And I would start with making sure that everything for the arduino is setup right. Right caps for your crystals and such. Though I guess a good question to ask is

Does this mean no matter what pwm output you use? write some test code check pwn in a non party mode 2 setting make sure its not a code oversight and go from there.

I've been spending this weekend re-creating the controller board in a more permanent form than on a breadboard. I discovered that as long as I run the microcontroller off an isolated supply, everything works fine, so I'll probably just build a little switching power supply to step down from 12V for the microcontroller, or else add tons of power smoothing between the fans/LEDs and the microcontroller. I started with this control board:


Here's what it looked like in-situ, after I unravelled some extra-long power wires that should have been buried in a deep grave at midnight (next to what the fans look like at full speed):


Here's three shots of the controller board that I created. First, with the 7 transistor-Darlington pairs that control the fans and step a 5V digital signal up to the 12V that the fans need:


Now the finished board, with the 7 fan control sections at the top, and the 6 RGB LED control sections at the bottom. The middle socket is for a ribbon cable that goes to the microcontroller's board.


Here's the back side of the board. The black wires are the high-current grounds for the LEDs, since each individual LED can pull up to 3W, and each individual diode within the RGB LEDs 1W. I have my RGB LEDs ganged in pairs, so each of those black wires is responsible for up to 400mA at 5V.

Looks awesome and looks like I wont fry my self next time I poke it

Random progress report: started playing with alternative FFT code, including learning how to directly manipulate the Atmega328p's ADC module. I also replaced one of my fans with a spare with brighter LEDs, and I'm rather baffled to find that the LEDs on only the top two of the seven fans see to be 12V LEDs. I didn't know that was a thing. I didn't get a chance to do much with the software yet, but I shall persevere. I might have to learn to manipulate the PWM module directly too.

Sounds like a plan to me the arduino libraries are nice but they lead to ...rather inefficient code In my honest opinion. I cant wait to see the craziness you make happen with understanding the hardware properly to be able to code efficiently on it. Also losing the arduino cruft saves like 2KB of compiled code its kinda gross.

As you say, they make the barrier to entry extremely low, but there's a lot more you can do by understanding the hardware. Thanks! As a note to myself, here's the documentation I need to keep track of for this evening's coding spree:
:: Atmega328p ADC summary
:: Atmega328p documentation (official PDF)
:: Digital port IDs for direct manipulation
:: PWM pin-to-timer mappings
:: PWM timer register usage

Edit: A productive evening. I stripped my ADC interrupt example down to the bare minimum, got it working, then extended it to sample two channels back and forth, and tweaked the ADC prescaler so that it can still collect the same number of samples per second. I implemented FFT and other signal-processing code based on Piccolo to process one bass and one wide-spectrum view of the total signal, and wrote in tentative code to write that information to my fan VU meter. I will test it out with an audio signal tomorrow.

*bump* I want to test the output of my signal-processing code, but I'm running into an Atmega328p issue that makes no sense to me. The following code causes all 7 of my fans to light up:
Code:
The following very similar code causes my Atmega to enter what seems like a stuck loop, and to remain stuck unless I unplug it and plug it back in at the right point:
Code:
Does anyone have any idea what's happening? Maybe my compiler is being an idiot?

Edit: I narrowed it down. The issue was the compiler optimizing out an array access, and when that array access is not optimized out, it causes the program to die. Here's the code that doesn't work:
Code:
Specifically, the meter_seq[] access. If I change the (i-1) to a constant like 0 or 1 or 6, everything works fine. What?!

Edit #2: Also, my current workaround is this, which just computes the 7 array values:
Code:

*bump* Note to self: Tari recommends seeing what happens if you put the array in progmem. I'm also going to try doing the array access math as math and see if that makes a difference by any stroke of luck. I also started writing the PWM functionality that I'll need for adjusting LED brightness using the information in the extensive Atmega328p manual.

*bump* I have gotten a great deal done since I last updated this topic:
- Finished implementing and testing bare-AVR PWM
- Later converted my fan-control code to use only 3 data pins instead of 7, pushing data into a latching shift register (74HC595)
- Replaced the two LEDs on the right side of my room that had blown-out green elements. The two LED pictures at the bottom of this post are of those LEDs undergoing post-soldering testing.
- Added a Bluetooth serial module from DealExtreme. Successfully tested controlling modes from my computer via PuTTY. Currently learning Android App programming so I can make an Android App to control the PartyMode system.
- Learned how to put the serial module (an HC-05, for what it's worth) into AT command mode and change its name to PartyMode2 and its passcode to something other than 1234.
- Implemented a "Romantic" mode that emulates the color, intensity, and flickering of candles. I'll post code for this if anyone is interested.
- Re-wired the breadboarded version of the controller circuit. I'm currently working on designing a PCB for this circuit, which I will get fabbed via OSHPark once I have all of the pieces laid out on this breadboard (below).

I would like to see the code if you don't mind. this project looks like it's going along great! I can't wait to see the finished project!

I fully plan to release the schematics, plans, construction instructions, and code when I complete the project. For now, does anyone have a minute to sanity-check this board design I've come up with for the controller? I have breadboarded everything except that switching-mode power supply in the upper-right of the schematic, and the board passes ERC and DRC.




Edit: Because Digikey shipped me my passives ridiculously fast via USPS, I was able to build and test my switching-mode power supply on a breadboard, and it works perfectly. On the other hand, I realized that one of my capacitors (the 300uF one) is much larger than the footprint on my board design above. Therefore, I rearranged things and re-routed. Comments/obvious bugs?

*bump* I ended up just doing lots of proofing myself, and after more component package replacement, silkscreen adjustment, and component rearrangement, I came up with a final design (for now). I submitted it to OSHPark, with an estimated turn-around of about 12 calendar days. That means I'll be forced to finish up the software, both the Arduino control firmware and the Android app, while I wait for the board.

*bump* Friday night through a great deal of work I got the first rudiments of the Android app to control the PartyMode 2 system over Bluetooth working. The app has two sections (in Android parlance, Activities): scanning and listing nearby Bluetooth devices, and controlling the attached Bluetooth serial PartyMode 2 device. From the control screen, you can change the system's mode, as well as perhaps more impressively choose the room lighting color from the RGB spectrum. I'm currently working to debug the Arduino program sending back the current mode to the Android app over Bluetooth serial.

Looking awesome. Debating on borrowing some of your code to make an RGB nightlight for emily. Code would need some minor modifications (mostly removing features who would have guessed ) and a very different pcb design. But hey I can do that