HowTo: HD120 RGB Custom Lighting Controller

Interesting. I think that may primarily have to do with the serial offloading interupt.

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:

Interrupts events (that is, noticing the event) can occur at any time, and most are remembered by setting an "interrupt event" flag inside the processor. If interrupts are disabled, then that interrupt will be handled when they are enabled again, in priority order.

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

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.)

Well, that makes sense. If something is software controlled and no commands are sent, it's boring. :) Kind of like turning on an RC car and staring at it, expecting it to do something when the controls are sitting on the counter.

Even in the February code, see the breakfast() function for what sets the gSettings from the serial input. Serial for breakfast(). *Nods Sagely*

In any case, going red and staying there on initial installation sounds unfortunately accurate, and is considered a bug. It should normally default to the new version of Angry Myia Mode. I'll have to revise that. I didn't want to make a Demo mode that would Do Things if it received no configuration, since boring is technically better than "OMG MAKE IT STOP!!!" stuff if it doesn't get directions.

As such, if you don't tell it what to do properly from the computer and the USB port, it will not do anything interesting.

So, for example, on the newer 0.2.0.0 code, if you want it to do something more interesting, like, say, Spinning Rainbow on fan 1, then send via Serial:

>1,0,2>1,2,21>1,7,60

This is:

> = Apply change immediately

1,0,2 = Setting group 1, item 0, value is 2

So those three are all address group 1 (Fan 1), and setting Item 0 to 2, item 2 to 21, and item 7 to 60.

I'll be the first to admit that currently the readme is out of date and doesn't explain the modes or possibilities. O.o So looking at the code:

Item 0 on a fan is always the mode. In this case, Mode 2.

In mode 2:

// Settings: 1 = Chance of Sparkles (0-255); 2 = Hue Steps per LED -- 21 shows a full rainbow; 7 = Speed of Rotation

Speeds are generally in BPM and all settings are 0-255 integers in all cases. The hue steps in the code are 0-255 (Which is explained and mapped out in the Readme) so 255/12 LEDs = 21.25 therefore 21 gets a full rainbow on setting item 2, and 60 on item 70 makes it rotate once per second.

"But what if I get my fans alllll set up awesomely and then want to make them stay that way when I restart the computer?"

Send just a ! to save the settings and they will be loaded on startup, or manually if you send $

"I hate commas!"

Well, then use periods. Or q's. Or nearly anything that's not a number. The same command can be

>1.0.2>1.2.21>1.7.60

or

>1q0t2>1&2B21>1-7=60

"Not enough q's! I want to qq more!"

It actually doesn't care how many characters you send between the numbers, but it will pause in fan updates while it's reading them. Either way, yes, you can do

>1Set0as2>1Set2as21>1OMGPleaseSet7asSomethingAroundOrEqualTo60

"What if I hate fan 1?!"

Perhaps set fan 2 then? Or five? Up to you:

/*---- SettingGroups ---------------------------------------------

// 0 = Global

// 1 to NumberOfFans = Per Fan

// NumberOfFans + 1 to NumberOfFans + NumberOfStrips = Per strip (For example, 6 fans and 4 strips, 7-10 = strips

"What do the setting items mean?"

//---- SettingItems ----------------------------------------------

// -- Global ================\

// 0 = Remembered Global Brightness

// 1 = Global Mode

// 2-5 = Global Mode Data

// 6 = Sync BPM

// 7 = BPM

// -- Per Fan or Strip =======\

// 0 = Mode

// 1-7 = Mode-dependant data

"What are all the mode stuff?"

//-- mode0() -----------------------------------------------------------------------------------------------

// Hue Shift

// Settings: 1 = Starting Hue; 2 = Ending Hue; 3 = Hue Offset; 5 = Phase Offset; 7 = Rate in BPM

//-- mode1() -----------------------------------------------------------------------------------------------

// Single Spinner

// Settings: 1 = Hue (Overridden by 3); 2 = 0 -> Clockwise, 1+ -> Counterclockwise;

// 3 = Rainbowmode? 0 -> No, 1+ -> Rainbow; 4 = BPM of Rainbow shift;

// 5 = Blade Offset; 6 = Fade Speed (good to match BPM); 7 = Spin Speed BPM

//-- mode2() -----------------------------------------------------------------------------------------------

// Rainbow

// Settings: 1 = Chance of Sparkles (0-255); 2 = Hue Steps per LED -- 21 shows a full rainbow; 7 = Speed of Rotation

//-- mode3() -----------------------------------------------------------------------------------------------

// Four-point spinner

// Settings: 1 = Hue (Overridden by 3); 2 = 0 -> Clockwise, 1+ -> Counterclockwise;

// 3 = Rainbowmode? 0 -> No, 1+ -> Rainbow;

// 4 = BPM of Rainbow shift; 5 = Per Blade Hue Shift; 6 = Fade Speed (good to match twice BPM);

// 7 = Spin Speed BPM

//-- mode4() -----------------------------------------------------------------------------------------------

// Double-scan

// Settings: 1 = Hue (Overridden by 3); 2 = Rotation Offset; 3 = Rainbowmode? 0 -> No, 1 -> Rainbow

// 4 = BPM of Rainbow shift; 5 = Per Blade Hue Shift; 6 = Fade Speed (good to match BPM);

// 7 = Spin Speed BPM

//-- mode5() -----------------------------------------------------------------------------------------------

// Double Spinner

// Settings: 1 = Hue (Overridden by 3); 2 = 0 -> Clockwise, 1+ -> Counterclockwise;

// 3 = Rainbowmode? 0 -> No, 1+ -> Rainbow;

// 4 = BPM of Rainbow shift; 5 = Per Blade Hue Shift; 6 = Fade Speed (good to match BPM);

// 7 = Spin Speed BPM

//-- mode6() -----------------------------------------------------------------------------------------------

// BPM from 100-line demo

// Settings: 7 = BPM; 1 = Hue multiplier; 2 = Beat multiplier

//-- mode7() -----------------------------------------------------------------------------------------------

// Split Sides

// Settings: 7 = BPM of pulse; 1 = W Side hue; 2 = E Side hue; 4 = Fan Phase Offset; 5 = Per side phase offset;

// 6 = Pulse? 0 -> No, 1 -> Sin, 2 -> Sawtooth In, 3 -> Sawtooth Out, 4+ -> Triangle

//-- mode8() -----------------------------------------------------------------------------------------------

// Split Quarters

// Settings: 1 = NW Side hue; 2 = NE Side hue; 3 = SE Side hue; 4 = SW Side hue;

// 5 = Per side phase offset;

// 6 = Pulse? 0 -> No, 1 -> Sin, 2 -> Sawtooth In, 3 -> Sawtooth Out, 4+ -> Triangle

// 7 = BPM of pulse;

//-- mode9() -----------------------------------------------------------------------------------------------

// Set RGB Color

// 1 = R; 2 = G; 3 = B

//-- mode10() -----------------------------------------------------------------------------------------------

// Fade to Black (No further color changes)

// Settings: 1 = Fade Rate

"What if I just want one color on the fan and to have it be boring?"

You can use mode...

0 with the same start and end hue.

1, 3, 4, or 5 with no fade, a hue, no rainbow, and no per blade hue shift

7 with both sides the same color

8 with all four quarters the same color

or 9.

"White?"

Mode 9 RGB 255 255 255

"Why are your comments in the code inconsistent?"

Because it was not originally meant for human consumption. Just fox consumption.

"Can I...?"

Maybe.

"You don't know what I was going to ask!"

That's true, but it doesn't change the answer.

"How did you make that musical demo video?"

I used Cygwin bash shell to make writing to the serial port easier and used a lovely shell script with Beatsync speed in Global Setting 6. Beatsync uses staging moves and sends a prompt after each staging move. Send the next set of settings to stage at that point and on the next beat they will go live, then send the next prompt.

Tell the shell script to wait for the prompt, then send the thing. Each wait is one beat. Sending stuff to stage takes ^ instead of > (while the < character moves stage to live)

I really should make a way to get the status of stage. Currently you can read the live settings back with ?.

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. :)

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.)

Encountered and overcame. See the remap() function. ^.^ That is why there are two LED arrays for the fans. If you are "facing the front of your fans", the cables should come out the upper half of the right side for proper orientation with the base code.

Making things generic for "anyone else", however, could be impossible without forcing them to install their fans in a specific orientation, etc.

Very true. Especially since LED arrays can't be defined dynamically. The ASM optimizations in FastLED require a specific LED array set in SRAM.

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.

It occurs to me in retrospect - especially given (I think your?) the query about that - that the +5 to the controller (RAW) from the hub is completely unnecessary as long as the USB connection is present. Not having that would solve the issue described.

Soldering (on the back) isn't as bad as I expected. I didn't have to dig out the braid even once (yet.)

I thought the same. ^.^

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.

Ah, good, so it does sound like you've got a mapping function running. It might be of some interest to compare remapping theories and see if they can be combined into a controllable switch. The only downside is that I know that remapping "Arbitrary facing and rotation of each fan" would end up being a potential pain in the tail. Moreso since that needs to run just before every display call which could easily end up slowing things down substantially.

Anyway.. just wanted to post letting you know that I'm enjoying your work and really appreciate it. :)

Good to hear.

Have you had better luck figuring out what I was doing with the software control and such in the code as well?

edit: added actual code samples

Encountered and overcame. See the remap() function. ^.^ That is why there are two LED arrays for the fans. If you are "facing the front of your fans", the cables should come out the upper half of the right side for proper orientation with the base code.

...

Ah, good, so it does sound like you've got a mapping function running. It might be of some interest to compare remapping theories and see if they can be combined into a controllable switch.

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..

Have you had better luck figuring out what I was doing with the software control and such in the code as well?

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.

@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?

@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?

Yup, that would almost invariably be the situation and the solution both.

Not sure if the Arduino is overloading or the USB port is, but invariably there is a thermal fuse tripping and resetting repeatedly and causing the half-on-ish effect.

A normal diode placed on the line from the hub to the Arduino would allow flow from the hub to power the Arduino if there is no USB, and would prevent backflow to the hub in S3. Just make sure it's aligned correctly and you'll be fine.

Thanks for great software! I wouldn't pay 60 € just to get a better Controller especially because i don't need the LED strips. I just have the Probleme that no matter how high i crank the BPM up (max 255) it is still spining extremely slow also the Flash effect remain for about a second, an idea what the cause of this is?

If you're using 0.2.0 version of the software, you can dump the current settings by sending a question mark. I should be able to see if anything is wonky in that.

Which flash are you referring to? Global Mode 2? That is a specialty function that triggers a single flash once, and -should- last for about 16ms, or one frame. A single-strike strobe effect. It was the flashes at the start of the music video. It's meant for real time "special effects" like in the video.

If the gmode2 flash is there for about a second, that indicates that the Arduino is sending a lot of serial data back to the computer that is not being read. On my system, this reduces it to about 15 FPS as it argues with the serial buffer.

I really, really need to make some examples of settings and document things better. O.o

So these are my setting haven't really chanced much yet, except the mode:

^0.0=128 ^0.1=0 ^0.2=0 ^0.3=0 ^0.4=0 ^0.5=0 ^0.6=0 ^0.7=6 <

^1.0=2 ^1.1=50 ^1.2=21 ^1.3=0 ^1.4=0 ^1.5=0 ^1.6=0 ^1.7=255 <

^2.0=2 ^2.1=0 ^2.2=21 ^2.3=0 ^2.4=0 ^2.5=0 ^2.6=0 ^2.7=255 <

^3.0=2 ^3.1=0 ^3.2=21 ^3.3=0 ^3.4=0 ^3.5=0 ^3.6=0 ^3.7=255 <

by Flash i mean the mode setting 1

So these are my setting haven't really chanced much yet, except the mode:

 

by Flash i mean the mode setting 1

Global mode 1?

Hmmm... The particular settings sent result in a Very Fast Spinning Rainbow on stock code, about three spins per second.

I noticed that there are three fans included on the settings. Did you skip the other fans or modify the code before compiling it?

What Arduino type did you use?

I only have 3 fans so i changed it thinking it wouldn't have a big impact but it seems that as i reversed the changes its working fine now.. hmm. Thanks for the Help !

Glad to hear things are working well.

Did you know that when you dump settings, you can paste any settings line in to create the same effect on the same fan later?

If you have any questions about the code prior to my documentation work, let me know And remember to save your settings if you don't want to have to re-enter them every time you restart. :)

It shouldn't have a big impact.

I think I may know what happened. I suspect you set Strips to 0, and the code probably doesn't actually understand such a thing. It's still trying to do stuff with strip LED addressing and operations despite having no strips to address. I'll probably do a quick test here and revise the code if it comes up positive.

Leaving it as it won't hurt anything. I might just take out the concept of "Change this to what you need it to be", since addressing all the things doesn't hurt normal operations, but it'll definitely make a settings dump bigger, so we'll see.

So I am planning on getting 3 HD140's and 3 HD120's. I will have several extra fan/lighting controllers that I won't use. Can I sacrifice one of those to do this?

Also I see where you solder the wires onto the Pro Micro, but where do those go to exactly from there? And how is the Pro Micro powered?

I have one of the Cablemod RGB lighting kits that has a sata to 5v could I use this somehow for this project. Specifically I have this kit

https://www.newegg.com/Product/Product.aspx?Item=9SIAA6P3S85934

So I am planning on getting 3 HD140's and 3 HD120's. I will have several extra fan/lighting controllers that I won't use. Can I sacrifice one of those to do this?

 

Also I see where you solder the wires onto the Pro Micro, but where do those go to exactly from there? And how is the Pro Micro powered?

 

I have one of the Cablemod RGB lighting kits that has a sata to 5v could I use this somehow for this project. Specifically I have this kit

https://www.newegg.com/Product/Product.aspx?Item=9SIAA6P3S85934

You can sacrifice the controller box for both its cable to connect to the hub as well as the housing itself to hold the end result.

The Pro Micro gets power from the USB connection to the motherboard and/or the 5V line from the hub (with a diode), so no extra SATA connectors required unless you want to power LNP strips as well. The HUB for the fans is necessary and has a SATA power connector.

I have not looked at the HD140 RGBs yet (And unfortunately the lovely 570x will not handle three 140s at the front) so I cannot guarantee they will work unless they can work with the existing HD Controller as well.

It looks like the HD140's have 12 lights in them and they do seem to work off the same HD controller as they are the same ones that come with either kit.

EDIT: Yea they do have 12 lights in them according to Corsair's own store page on them

http://www.corsair.com/en-us/hd140-rgb-led-high-performance-140mm-pwm-fan

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

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

Hmm. Yes, absolutely can. Or you can pull another data pin from the Arduino (assuming you're using that). Strips connected to the hub with this controller would have an interesting time "looking like flat fans" due to the remap, but otherwise that would be fine. Grab +5V, Ground, and Data Out from the hub and take them to the power rails (+5/Ground) on the strip and the data in side of the strip.

Current-wise, the SATA connector can provide 4.5A and each LED will pull up to 0.06A, so the hub can support up to 75 LEDs altogether.

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.

garyd9: The supply voltage is all in parallel for the fans. You can just use the next one to run you LED strip without much problem.

So, I started playing with this the other day and the CLI was super confusing at first, but I finally got the hang of it. Changing it manually was still a PITA so I wrote a quick app in Processing today to make it a little easier. It's just a direct interface to the settings, but hopefully, I can grow it up over the next few weeks.

It's up on my GitHub here: https://github.com/ILAMtitan/HD120HostController

To use it, you'll need the latest version of Processing: https://processing.org/

and Control P5: http://www.sojamo.de/libraries/controlP5/

Start processing once, and it will create a "Processing" directory in your documents. Just drop the controlp5 library folder inside the "libraries" folder there to install it. After that, just open the PDE and hit the triangle. If you're happy with it, you can also export an exe so it's easier to run.

Once you get it open, just select the com port of the Arduino, the fan you want to configure, and the mode you want. Once you get the settings tweaked, hit send to update it. If you change the fan number, the rest of the settings will remain, so you can get them all the same if you like. Once you like it, just hit SetDefault to save it all to the controller.

A lot of the ranges for the sliders were kinda guesses, so any feedback on better ones would be appreciated. Actually, any feedback at all would be good.

Still on my todo list:

Tweak slider ranges

Optimize interface

Implement the Global Settings (Once I figure out how they work)

Clean up code

Document (notice this is last, so no guarantees)

@garyd9 -

Looks like I missed answering that before somebody else did. Yes, power in the hub is parallel. LEDs generally need to be powered in parallel, or a "package" may consist of several in series and then power in parallel to each package. Each LED in the fan is one package on its strip, and in the hub it's parallel to all the strips (otherwise there would be voltage drop from power consumption).

@ILAMtitan

O.O

Wow. ^.^

It'll be a short time before I can look at that, but I can at least answer some questions here. :)

Trust me, I agree that changing it manually is a PITA. I don't recall if I committed the "All fans one set" and "Single fan mass set" changes to the main code yet. I should probably make an "All fans mass set" too Just Because if I haven't already. O.o

Value Range:

Currently documented in code comments. Some are specific settings, some are 0-255. On some of those values, the step granularity is the main thing. For example, on the spinner, blade offset can be 0-255 integers, but changing from 0 to 1 would be mostly useless as it would cause the timing of that blade on the spinner to be 1/256th away from the others. Values like 128, 64, 32, and such make much more sense. There are some cases where a 1-step granularity makes sense or can achieve some fun things, but not most places.

It's also possible to "Pre-program" sub-modes from a computer app too. For example, "single spinner" with 0 fade rate and rainbow mode becomes a rainbow sweep and not a spinner. :)

Global Settings...

Setting them is the same as fans, just "Fan 0", and the item and value.

The easiest one is Global Brightness.

Currently only three global modes. One "nothing extra", one "effect" mode specifically made for real time controls. and one that allows any other mode to be pulsed on and off. "Flash" only takes effect on one fan once, so only makes sense for a program constantly telling the LEDs to do things.

Sync BPM is for real time or live control. It causes the controller to move data from staging to live on a timing beat, then send a ping to the computer to say "It's safe to send me more data now". So the computer can send staging data after the ping and know it will take effect on the next beat.

BPM is on item 7 for consistency. In "the vast majority of modes", primary BPM is on item 7. :)

Great project. I'm tempted to start dabbling but was wondering if McGyvering a gadget like this could also control these fans... cheap and easy is good sometimes.

https://www.amazon.com/Mokungit-DC5-12V-Controller-Effects-WS2812B/dp/B01H3CEZDU/ref=sr_1_5?ie=UTF8&qid=1497194397&sr=8-5&keywords=ws2812+controller