garyd9

I'm curious... do you remember from when you had the hub opened up, if it's supplying voltage to each fan connector in series or in parallel? The LED order remapping wouldn't impact me due to the way I'm using a translation array instead of dynamically remapping.

Been using this for a while, and now I'm wondering if I can chain a generic WS2812B LED strip in the system. I'm only using 4 fans on the hub, so I'm curious if I can grab three pins from the 5th hub connector for +5v, GND and DATA and wire them to the strip. (Assuming the strip is <= 25 LED's to prevent drawing too much current.) If I'm not using the 6th hub connector, I don't think there's any need for the "data return" line to be connected. @Charixfox, being you've taken the time to pull the hub apart and examine it (as well as the fact that you seem to have a very good idea what you're doing), do you have any thoughts on this idea? Thanks Gary

@Charixfox, you seem to be more proficient in the wiring aspects than I am... I'm wondering if the oddness I see in S3 is due to the USB being powered (+5v, 500 mA), and it simply running out of enough current to power the arduino AND 48 LEDs. (Just the LED's would take around 900 mA, I think.) If so, and relying completely on "Electronics 101", the USB power is leaving the arduino via the RAW pin, and there's nothing in the fan hub to prevent current inflow from it's +5v out line. If this is the case, would the problem be solved with a simple diode? I'm kind of (extremely) rusty, but wouldn't a diode placed between the RAW pin and the hub (and wired in the correct direction) prevent +5v from flowing from the arduino to the hub? Would there be any other side effects?

edit: added actual code samples I took a less calculated approach and just set up a remap array. So, when filling the leds array from a palette, I do something similar to: const PROGMEM uint8_t BottomUpPattern[] = { 7,8,6,9,5,10,4,11,3,0,2,1,19,20,18,21,17,22,16,23,15,12,14,13,31,32,30,33,29,34,28,35,27,24,26,25, 43,44,42,45,41,46,40,47,39,36,38,37}; ..followed by... for( int i = 0; i < NUM_LEDS; i++) { leds[pgm_read_byte_near(BottomUpPattern + i)] = ColorFromPalette( currentPalette, colorIndex, brightness, currentBlending); // This abuses the tendency of 8bit uints to "roll over" or "wrap around". In other words, "0 - 1 = 254" colorIndex -= PALETTE_SEGMENTS; // defined as (256 / NUM_LEDS). } I can swap to different remap arrays for different effects with minimal effort. So, if I want a more racetrack type pattern, I just swap in a different remapping pattern: const PROGMEM uint8_t RaceTrackPattern[] = { 2,3,4,5,6,7,8,9,10,11,0,1,19,18,17,16,15,14,32,33,34,35,24,25,26,27,28,29,30,31,13,12,23,22,21,20}; (note: the racetrack pattern only uses the first 3 fans, so I use a different NUM_LEDS and PALETTE_SEGMENTS definition for that.) Consider the example of the palette shifting... using the LED's in order, it gives a spinning effect. Using the exact same code, but remapping the LED's, changes the "motion" effect to whatever I want. I like using the FastLED built in "lava" palette with the leds remapped to "flow" from the bottom to the top. Being in the US, I find a palette of Red/White/Blue mapped to flow left to right is also appealing. Of course, this ONLY works because I know the exact position of each LED. I think this is one of those cases where there really isn't a great solution to the problem simply because the problem is that humans install the fans. When I installed my HD120's, I didn't align them all the same due to some consideration of the LED order, but more to align the fan wires with the areas in my case that I can run wires without them being visible. Also, due only to my OCD, the fans are plugged into the hub in a specific "bottom to top" order instead of just randomly plugged in. It was just a happy coincidence that it worked out cleanly for me, but to share this with the "John Doe's" of the world, either the user would have to be very careful installing (or reinstalling) their fans, or there would have to be some kind of setup software to determine the position, orientation and direction of each fan. Actually... that isn't a bad idea.... Use PC software to send commands to the arduino to light up specific LED's and the user would provide feedback on where the LED was lighting up. From that, the position, orientation and direction of each fan could be determined, then an array could be built, sent to the arduino, and stored in EEPROM.... Sure, it gets complicated with 6 fans positioned across the front, top, back, bottom and sides of a case, but it is doable.. Yes. It didn't occur to me at first that you both expected serial input to control, and that you used overlapping effects. As for the USB power thing... I've actually switched sides on this one and prefer that the arduino gets power from the fan hub. The fan hub connection is permanent while the USB connection may or may not be. For USB power, there's a questionable low power state that the arduino doesn't seem to like when the machine is in S3. Windows isn't giving me the option to control power to that port, and I honestly don't trust Windows in regards to USB settings being retained anyway. I've often seen Windows lose USB standby settings for my mouse (I configure it to NOT allow wake from sleep, but often find that Windows has reverted that setting.) The fan hub +5v is much more predictable: If the machine is in soft-off or S3, there's no power. If the machine is on, there is. It's not influenced by the OS. I'm also starting to see the USB as a temporary thing in long-term usage. I might plug the USB in to update the software, change fan mappings, or even preload different "modes", but once I'm done with that, I unplug the USB cord and rely on buttons to toggle modes/colors/etc. Of course, once I start trying to have dynamic control of the fans via the OS (such as your music demo), I'll probably reconsider that opinion. When I reach that point, however, I might end up jumping to an ARM based board that doesn't suffer the interrupt issues of the AVR boards.

Playing with this is too much fun. ;) One issue that you've obviously already encountered is how to handle addressing specific LED's in a specific order. Thankfully, all my fans are installed facing the same way (relative to the front of the case) and with the power cords coming from the same position. So, I'm lucky in that the first LED for each fan is always in the "1:30" position (and then they work around counter-clockwise.) Of course, if I want to light the bottom-most LED, it's still annoying to figure it out. (In my case (no pun intended) the LEDs at the very bottom are 7/8.) Making things generic for "anyone else", however, could be impossible without forcing them to install their fans in a specific orientation, etc. I've also learned to unplug the USB cord before walking away from the machine. If my box goes into sleep (S3), there's still a tiny bit of power coming over the USB and it leaves the arduino and the fan LED's in a "kind-of" powered state. I don't know (and haven't measured) if the power is going out from the RAW or the data (pin3 in your setup) pin, but it's enough for faint LED illumination on the fans. I'm not sure if it can cause a problem or not... so I just try to remember to unplug USB if I'm not using it. I read somewhere about someone removing a FET from a "uno" board to prevent power over the USB, but I suspect that'd be beyond my abilities. Soldering (on the back) isn't as bad as I expected. I didn't have to dig out the braid even once (yet.) Someone earlier in this thread posted sample code that just pushes FastLED palettes through the LED's. (The code appears to be a copy of demo code for the palette functions.) I've been having a blast manipulating that. Instead of letting the palettes "spin", I remap the LED's so they "rise" from the bottom of the lowest fan and "rise" up to the top. The problem, of course, is that the mapping is specific to my installation of the fans. Anyway.. just wanted to post letting you know that I'm enjoying your work and really appreciate it. :)

neat. Just soldered up some wires and am playing with your code. My initial WORKING runs were extremely disappointing.... I had loaded your current github code (as of the timestamp of this post) and all my fans went red and stayed there. Very boring. ;) Thinking that there was something wrong in the code, I copied from a commit you made on Feb 6th (https://github.com/Charixfox/HD120-Controller/blob/77d9d8e7c9320b0039eb222f5db107223e06bbf5/HD120-Controller.ino) and found it also... boring. Then I actually looked at the code and realized that you have different "modes" and nothing seems to change the modes. If I manually re-order the modefun array, things are more interesting. Shoving the following line into a loop in initSettings() also makes things more interesting: gSettings[i][0] = random8( NumberOfModes - 1); The code (from Feb) is kind of odd in that it uses gSettings all over the place, but initSettings() always intializes the entire 2 dimensional array as 0's, and I don't see anything that changes it whatsoever. I did also spend a moment to solder a pair of wires to test button presses. Hmmmmmm. :) BTW, I also ordered a UNO "starter kit" so I can play with arduino in general. Somewhat unrelated... I wasn't able to get things working properly following your instructions for getting the board set up in the IDE. What I ended up doing was following the instructions here: https://learn.sparkfun.com/tutorials/pro-micro--fio-v3-hookup-guide. That made it easier. :) Oh, and I can handle soldering wires on this board (mostly.) I had to dig through some older stuff to find lead-based solder (lower melting point and generally easier to work with.)

...at risk of dragging this thread even further off topic... Here's an interesting page I found that goes into massive detail on interrupts on the Arduino Uno. (I think interrupts on the pro micro will work the same.) Scroll down (or search for) "Can interrupts occur while interrupts are disabled?" http://gammon.com.au/interrupts This seems to indicate that the interrupt will cause an "event" flag regardless of if interrupts are disabled or not, and then when interrupts are re-enabled, the handlers for the flagged interrupts will get called: Obviously, the only way for me to REALLY know if this will work will be to set up a test case: attach an interrupt handler to a pin with a button, run a sketch that disables interrupts for a period of time, press the button during that period of time, and then see if the handler gets called when they are re-enabled. ... I'm starting to regret I didn't go ahead and get a breadboard and pin'd version of the Arduino board... it would make testing some of this stuff much quicker. Maybe one of the full "starter kits" would work. Perhaps I should make ANOTHER amazon order... Take care Gary

Blah, that really sucks. As I had mentioned earlier, I've only been reading everything I can on this, not actually tinkering with it. Something I read on the FastLED wiki gave me the impression that they'd only be delayed: (emphasis is mine) (source: https://github.com/FastLED/FastLED/wiki/Interrupt-problems) It is a bit confusing when it suggests that "disabled" will result in interrupts being delayed (and not lost.) Oh, well. I guess I'll try it the interrupt way (only because I'm hard-headed) while being prepared to re-write it with polling. In fact, it might be a good thing for me to screw up a couple times, as it'd force me to learn more about what I'm doing instead of just blinding attaching wires. :) Take care Gary

Is there a requirement to use pin 3, or can I move that to any PWM capable pin? (I can't find anything documenting what capabilities the fan data out pin should have, but pin3 supports GPIO, PWM, half the i2c interface, and is interrupt enabled.) In particular, I'm wondering if I can move it to pin 5, which still has PWM, but doesn't have interrupts. (or does fastLED need the interrupt or i2c stuff that pin3 supports?) My reason for asking is that I'd like to keep the interrupt capable pins available for other things - in particular eventual user controls. I realize that fastLED will block interrupts, but my impression is that they are only delayed (and not shoved into a black hole.) Reacting to an interrupt (even one delayed) should be considerably faster than polling for button presses, as well as less error prone (and relieves me of the burden of polling for a button release after I see a button press in order to determine a "press/release" cycle.) I STILL haven't started putting this thing together even though I have the parts. That hasn't stopped me from reading everything I can and thinking a lot about it.

Now that I've read up a bunch on the board, and the source, etc.. I have a few more questions. ;) This might be basic electronics... (I have the feeling it is, but I'm missing something)... why bother connecting +5 to raw? From: https://learn.sparkfun.com/tutorials/pro-micro--fio-v3-hookup-guide That leads me to believe that EITHER the board is powered from this pin (taking 5v from it - treating it as 5v IN) OR the board is powered from USB, in which case the RAW pin is 4.8v OUT (and can even be used to power something else as long as it's very low amperage.) If less than 6 fans were plugged into the hub, would it be possible to attach to the first unused fan connector (on the hub) and send the data OUT back to the ProMicro... and then use that data to determine how many LEDs actually existed? From what I can tell, fastLED references the 1st LED in fan#2 as leds[12], and the 1 LED in fan#3 as leds[24]. In other words, the LEDs in multiple fans are treated as a single long strip (and not as multiple connected strips.) Obviously, I don't know the underlying protocol, but I'd imagine that FastLED sends out some type of signal saying "hey, set LED #14 to 0xff0000" and the 2nd LED on the 2nd fan turns red. Somehow, the 2nd fan "knows" that it's LED's are addressable as #13 thru #24. It seems to me that whatever mechanism is used to determine that information could also be used to determine when the chain ends IF the data chain continues back to the micro pro board... and so the code could theoretically determine how many LEDs/fans are actually in the strip. Of course, this assumes there might be some functionality within FastLED to accept that data and do something with it. (looking at the library reference, nothing jumps out at me... but I still have to wonder if the data could be extracted or not.) --- Some interesting ideas for different modes: Use the LED lights to represent a configured timer. The PC software sets "timer" mode with a timeout of (for example) 30 seconds... and the LED animation is arranged to "spin" with a full revolution completed in 30 seconds (and then the full set flashing at expiration.) All kinds of fun things could be accomplished with a thermistor or two attached... With multiple thermistors, a single fan could even show general temperature levels for multiple thermistors. I wonder if it'd be possible to tap into the 3rd wire (tach signal) in a case fan (or water pump's fan connector) to show a "color" animation representation of the fan/pump speed. (Some testing would be needed to scale things, of course.) This is going to be fun... Take care Gary

Wow, that's amazing. Not at all something I'd leave running all the time, but it's a cool demo of what could be possible. Amazon/USPS dropped off my boards and jumpers, but it might be a while before I have time to actually tinker with them :( I'm married with children (and a full time job.) Those things all want to take precedence over my hobbies. I also want to find some 2 pin male jumpers so I can easily plug my 460XRGB case's 3 buttons into the Arduino and use them to control things. (2 pin versions of the cables I already ordered should be perfect.)

This will be exciting. I've ordered a 3 pack of those boards and the suggested cables. My 3x fan "kit" will come tomorrow and the boards/cables on Sunday. Tomorrow, I'm also expecting delivery of a delid tool. If the delid works without any problems, I should be able to start tinkering with this stuff Sunday. (Otherwise, I'll be driving most of Sunday to get a replacement CPU.) Is the source code actually compiled (like C/C++), or is processed down to some type of intermediate code that's interpreted at runtime (like java or C#)? You keep mentioning the LNP, and I'm assuming that your refering to the corsair lighting node pro product. Is that also a required item? (My impression was that three pin cable plugs directly into the HD120 hub and that LNP wasn't part of the project.)

So 2.5k of "RAM" and 1k of persistent storage. That won't fit much. Are there variants of the same "Pro Micro" board that have more EEPROM or perhaps something that can use some type of external (USB based) storage? My concern is that 1k isn't likely going to be enough space for storing the program AND storing multiple custom complex sequences that can be switched via button presses. That's what she's worried about. I love writing code, and really enjoy embedded systems. I really miss the days of software development where you had to optimize code and profile it... and would write assembly to make things faster and smaller instead of just telling customers to buy more memory or a faster processor.

Sounds like it doesn't make sense to NOT get the cables. That might be feasible... As for shaky hands, I can solder a PL259 connector, or two wires together, but when it comes to pretty much anything surface mounted or on a PCB, I'm in trouble. Okay, I can handle that. I was concerned that it was yet another perversion of a real language. Sometimes I really wish these people would just create entirely new languages instead of variants of existing languages. It makes my life hard when the rules are "almost the same as" something else (but not quite the same... that leads the errors.) I can deal with processor differences, and 28K is a massive amount of space compared to where I started my development life. The thing about it restarting and not crashing, however, is disturbing. I wonder if there's a way to get the thing to actually crash in order to allow postmortem debugging. If it just restarts, you lose the state... So, currently, you have to use the Arduino IDE to change the lighting patterns? You say that you've also had it work the CLI... The windows command prompt? Is it just writing to a COM port? That would probably be enough for me to get excited. ;) I'm thinking of the three button controller thing that comes with the fans (and with the corsair crystal cases.) The speed button could probably retain it's purpose. I'm not sure about the other two, but if the light patterns can be represented as strings of bytes, then perhaps the buttons could just change the "current" string. So, for example, you use software to pre-load 5 or 6 of your favorite patterns into the Arduino's memory (from a virtually unlimited library stored on the PC.) Then you can use the hard buttons to step through the different patterns. ..That leads to another question: Is the memory on the Arduino board persistent, or does everything have to be reloaded each time power cycles? BTW, my wife just caught me reading/replying to this post (with an amazon page open in another browser.) She now hates you. LOL. Her words: "Between hockey playoffs, you delidding and getting your computer working, and now another project, I'm never going to see you again, am I?" :D:

Sounds interesting... I'll have to place an amazon order sometime this weekend. I just ordered a 3-pack of HD120 RGB fans (with the hub/controller) that I'm going to put into my 460X RGB case (to replace the SP120 fans.) Can I use that hub/controller in conjunction with your work? Oh, and I know how to solder.. and can even do it... but my hands tend to shake, which makes any precision soldering impossible. (For example, if I were to try and solder wires to the pictured board, I'd likely destroy any SMT parts on the board near the solder pad in the process.) Being that I'm completely unfamiliar with Arduino, can you suggest a "getting started with Arduino" type guide that would give me the rough overview of whatever "sketch" is, etc? (I'm a professional software developer with extensive h/w experience, so I can skip the extensive guide that starts with "this is a circuit", "a resistor is something that will create resistance (ohms) which will in turn lower amperage and raise voltage" type thing. I just never got around to Arduino, and it sounds like "sketch" might be yet another language. Why can't everyone just use assembly or C?) Does your project allow for only software control, or are there also provisions for control via momentary switches? Similar to the 3 lighting control switches on the corsair crystal cases... Thank you Gary