HowTo: HD120 RGB Custom Lighting Controller

Preview of my Fans Controlled, more effects on fans and same time work with 2 strips 30cm RGB.

 

More info, how is made soon.

 

http://i.imgur.com/cL2LJY3.png

 

Here is a video.

 

[ame]

[/ame]

Edited April 7, 2017 by cretzuadrian
Video

Preview of my Fans Controlled, more effects on fans and same time work with 2 strips 30cm RGB.

 

More info, how is made soon.

 

The info is the important part.

 

For example, you used a Nano and I used a Micro, which brings up which is better or which can do what. I know the Nano is USB Mini and the Micro is USB Micro, but the Nano is also about 20% less expensive. I do have both. Comparisons of wiring, my code is available to build stuff from, and it looks like you got some things working on your code that is more than what I have on mine so far, but also the random Demo-100. (Which is my prototype test of will it work and the source of my video.)

 

Code contributions, comparisons, and combinations. Collaboration and consultation and make everything the best it can be. It all works well.

 

Soooo, details! Code release! Stuff and Things!

Last video and code for arduino.

 

[ame]

[/ame]

HD120.ZIP

Last video and code for arduino.

 

I see you opted for a physical push-button and speed pot solution to the controls. That works.

 

You may want to consider allowing a brightness of 0 (Leds completely off) as an option in the system as well, just in case of headaches. ;)

 

In light of the LNP (no pun intended), I decided to make a version locally that would work with both the fans and the strips as separate entities. Rather than trying to string the strips onto the end of the fans or vice versa, I made a separate data pin running to the strips. I'll have to redesign the code to handle both sets of things. Kind of weird, the strips on the front inside sides of the 570x case fit just great, but colored LEDs shining into a black case is semi-meh.

cheap and easy solution ;)

 

Corsair HD120 LED and SP103E RF LED remote.

 

http://amzn.to/2pgSJ41

 

 

[ame]

[/ame]

Hmmm... *Looks and extrapolates*

 

Pros:

• Less wiring change required (It's still not Buy, Plug, Play).
  
• No code-wrangling required.
  
• Tons of variations on similar patterns (Over 300 variations total on about 27 patterns)
  
• Costs $10 pretty consistently (whereas the Pro Micro can cost anywhere from $5 in bulk to $8 for one to $20 for one depending on where you get it)
  
• RF remote control to push buttons on.
  

 

Cons:

• Still requires rewiring (Not plug and play) and possibly extra parts to get power to it happily inside the case, thus increasing costs.
  
• According to reviews, does not save its state or allow saves. Getting to a specific thing requires pushing the button over and over again to cycle through 300+ options.
  
• Can never be updated to do different things.
  
• Can never be software controlled
  
• Cannot easily be made to control Strips separately.
  
• Has no concept of per fan control. Just brute force the pattern across everything.
  
• Based on reviews, various versions of this may be of questionable quality.
  
• Based on official seller answers to questions, the seller has absolutely no clue what they're talking about.
  

 

Overall it's definitely an option. Since it should hopefully handle the 5V rail coming back from the strip direction, chances are it would not need an extra part to power it (we hope) making the barrel jack unnecessary. So at that point, rewire the output to the input on the hub and you're set.

 

I'll stick with my thing and continue to work on my software. By their definition of "modes" my current in-progress code has about 128,100 differentiated fan modes at the moment, can address each fan individually, can address each strip individually, and can save and load its settings on command, plus is software-controlled so has opening for future expansion. ^.^ However it does require more wiring to be done and honestly soldering it is preferred even though it's not absolutely necessary.

Charixfo, I've been watching this thread with interest and I'm wondering if you're yet at the point where you can give instructions to clueless people.

 

Well, perhaps not "clueless", but at least folks who don't want to solder (or are incapable of soldering anything smaller than their own thumbs), prefer Raspberry Pi to Arduino, and are familiar with Arduino only in the sense that they know something exists by that name.

 

While many folks wouldn't mind learning as they go, getting over that initial hump can be intimidating (and often expensive.)

 

Take care

Gary

Charixfo, I've been watching this thread with interest and I'm wondering if you're yet at the point where you can give instructions to clueless people.

 

Well, perhaps not "clueless", but at least folks who don't want to solder (or are incapable of soldering anything smaller than their own thumbs), prefer Raspberry Pi to Arduino, and are familiar with Arduino only in the sense that they know something exists by that name.

 

While many folks wouldn't mind learning as they go, getting over that initial hump can be intimidating (and often expensive.)

 

As long a s a preference for Pi doesn't become a need for Pi (You'd have to write your own code), it's relatively easy to make the full end product. You can make it without soldering, but you may need to fiddle with the connections in the future if you do. I was thinking about the heat shrink and I realized that the twist on method may not take well to the heat shrink, but I have no good way of testing at the moment. If you have a normal SD or HD controller that you can sacrifice, the pin-through connectors would make a better, more stable connection.

 

So let's get an idea for what you have and what you feel you can do.

Parts list:

Mandatory:

- Arduino Pro Micro (See attached Image)

- Micro USB cable - usually Motherboard Header to Micro USB in the case

- Wire

 

Tools: (You can use other things if you can make them work)

- Angle Cutters (Optional but recommended)

- Wire Stripper

- Diamond-tip (fine tip) needle nose pliers

- Fine phillips head screwdriver if you intend to sacrifice a standard controller

 

Highly Recommended:

- LED Light hub for the fans (I will not give directions for skipping this unless requested)

- Wire that terminates in female pin connectors. Some options:

---> Individual Jumper Wires

---> Cable from SP or HD Lighting Controller

---> 3-Pin Servo Extension Cable for RC devices

-- Note that without that female connector, you'd probably have to solder it to the board

 

Optional:

- 1/2 inch Heat Shrink Tubing

- Three pin MALE connector wire if you intend to have LNP Strips as well

- If you intend to have strips also, you -MUST- get another SATA or Molex power connector for the strips. It should be a SATA MALE connector (You can see the metal contacts) and do not use a SATA to PCI-E cable (That only has 12V lines and you need the 5V line)

 

I got the five pack of Arduinos at:

https://www.amazon.com/dp/B019SXN84E/

 

There are other options. Important things:

- Must be PRO MICRO, ATMega32U4, 5V. There are 3.3v versions (NO!!!) and Nano versions (Also No)

- I chose this over the OSOYOO version because of some bootloader issues described on the OSOYOO. The cost of Three Kookye is the same as one Sparkfun, just in case of epic failure.

 

For the cabling, I've used:

https://www.amazon.com/dp/B00MIQRN2C/

These will work for both the fans and the strips, but I worry about the power draw of the strips, so I got a fancy three-pin fan header extension cable (fancy not required, I just got a blue one) and cut off the tab on it for the strips. If you do not have strips, it does not matter.

 

I've also sacrificed an SP Lighting Controller for the cable. ^.^

 

Look at picture of Arduino attached.

See:

RAW

GND

3

4 or 5 if you have strips too

 

Strip end of wires that you will be using to go to the hub. Should be Stripped -> Wire -> FEMALE connector

 

The following directions are for Fan LEDs only, no strips. Ask if you want Strip directions too.

 

If you are using the above-linked servo wires:

Black will go toward PORT 6 on the hub.

On the Arduino:

Black -> GND

Red -> 3

White -> RAW

 

Make sure that stripped wires are very tightly twisted (You don't want any loose wire bits shorting to other connectors)

Stick stripped wire end through hole.

Twist. Tighten-twist with needle nose pliers if possible. Make sure there are no extra bits of wire touching other connectors on the board.

Result:

and

 

For software, download and install the IDE from Arduino.cc

Download the sketch from https://github.com/Charixfox/HD120-Controller

On the IDE:

Sketch Menu -> Include Library -> Manage Libraries...

Search for FastLED and install it

Load the Sketch downloaded from above

 

Tools Menu -> Board -> Arduino Leonardo

Tools Menu -> Port -> Look at what ports are currently listed and remember NOT to use them.

Plug the board in to the MicroUSB cable - NO LEDS attached unless the Hub has power connected!

 

Tools -> Port -> Select the NEW port that is not one listed that you remembered not to use

Click the "->" Upload button or Sketch -> Upload

Wait patiently for things to happen. If you do not see orange at the bottom part of the window, good.

 

--- After the first Upload, the Port will probably change. You will need to go to Tools -> Port and look for the new port. It will -probably- say "Arduino Leonardo" after the COM# now.

 

Notes:

The current controller sketch is the INITIAL RELEASE. I am working on some SUBSTANTIALLY better code right now. ^.^

 

I have taken some videos of the physical build process and may eventually make them into a How To video. Don't hold your breath on this though.

 

If you are not sure, or want more details, or have any questions, ask! I don't bite.

 

Teaser of new code Coming Soon™.

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

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?

 

Absolutely. Be aware that the hub does not get hurt, but the controller gets destroyed. I generally use the SP controller that comes with the case (I have a 570x) instead of the HD one unless you plan to re-use the SP fans. If you just get the servo cables mentioned in the thing, you don't need to sacrifice the controller. If you get 1/2" shrink tubing, you also don't need to sacrifice the controller (That is what I currently have installed. Shrink tube version. ^.^

 

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

 

"Shaky hands" is a very subjective thing, so I can't speak for anything in particular. If you decide to solder, I'd recommend that you put it front to back, then solder on the back side of the board. Nothing to destroy. I can't attach the example fvideo here though. Too big and I'm not keen on posting segments to YouTube.

 

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

 

I could suggest, which would involve "Go to http://arduino.cc/", but you're already ahead of the curve. A "sketch" is Arduino's fancy "Let's not scare non-programmers with Main and Loops and calling it 'Source Code'" word for "C++ Code for a specific platform and an IDE that knows how to compile for the particular chips and mangle the code a bit". So for the most part:

 

It's C, C++, and ASM.

 

The main() function is hidden and handled in the background by the IDE. Instead you write a setup() function that runs initial one-time setup code and then a loop() function that loops indefinitely in main(). The IDE and such basically makes void main() { setup(); while (1) ( loop(); } } ... There's other stuff, but yeah. :)

 

Certain programming rules don't apply because of the way the processor works. For example:

uint8_t i = 255;
i++; // i becomes zero and does not overflow the value into the next byte.
uint8_t x = i / 0; // x == 0. There is no Divide by zero error.
int8_t y = i / 0; // x == -1. There is no divide by zero error.

You have about 28.5K worth of compiled code space to work with.

If the code exits, crashes, etc, it just starts over again. (I've crashed it. ^.^; )

ASM is for the 8-bit AVR instruction set. Good Luck. <.<

 

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

 

The hardware and code as described are software only. Due to the number of settings in the various functions, it would be an interesting challenge to make a non-insane three-button control system that didn't require three tons of button pushes. <.< However if you decided to use buttons, you'd need to add wires to any other number pins on the board, and then pull them to ground to trigger. The arduino.cc site contains directions on how to read switches.

 

For software control, you can use the IDE, but I've also successfully gotten it to work with command line commands. XD

Absolutely. Be aware that the hub does not get hurt, but the controller gets destroyed. I generally use the SP controller that comes with the case (I have a 570x) instead of the HD one unless you plan to re-use the SP fans. If you just get the servo cables mentioned in the thing, you don't need to sacrifice the controller.

Sounds like it doesn't make sense to NOT get the cables.

 

 

"Shaky hands" is a very subjective thing, so I can't speak for anything in particular. If you decide to solder, I'd recommend that you put it front to back, then solder on the back side of the board. Nothing to destroy. I can't attach the example fvideo here though. Too big and I'm not keen on posting segments to YouTube.

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.

 

The main() function is hidden and handled in the background by the IDE. Instead you write a setup() function that runs initial one-time setup code and then a loop() function that loops indefinitely in main(). The IDE and such basically makes void main() { setup(); while (1) ( loop(); } } ... There's other stuff, but yeah. :)

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

 

Certain programming rules don't apply because of the way the processor works. For example:

uint8_t i = 255;
i++; // i becomes zero and does not overflow the value into the next byte.
uint8_t x = i / 0; // x == 0. There is no Divide by zero error.
int8_t y = i / 0; // x == -1. There is no divide by zero error.

You have about 28.5K worth of compiled code space to work with.

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

 

The hardware and code as described are software only. ...

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

 

Due to the number of settings in the various functions, it would be an interesting challenge to make a non-insane three-button control system that didn't require three tons of button pushes.

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:

I'm going to skip the quotes this time. ^.^

 

Some people just don't want to get the cables and others want the added stability of the pins in the official cable from the controller, and others like the black wire. O.o You can get any single-row, three-pin, 0.1" (2.54mm) female connector on the end of three wires though. Fan connectors are not good though since they are two-row (even though one is not used at all)

 

For soldering:

I have semi-shaky hands, but with a fine tip iron, I was able to successfully solder on the PCB better than I got two wires spliced. The helping hands kept the PCB stable better than the splice stayed, so I got a crooked splice. T^T

 

Language:

https://hackaday.com/2015/07/28/embed-with-elliot-there-is-no-arduino-language/

^.^

"It's C/C++ with added convenience libraries"

 

Reset:

Technically there are ways to debug, but for the most part unless you're doing something completely insane, there's little reason to. The worst crashes I've had are when I took my array of pointers to functions and didn't add pointers to the functions to the array after adding new functions. ^.^; So I ended up with it effectively calling code from an unintialized pointer and it got grumpy. Everything else is feedback from the lights for the most part.

 

Controls:

The Arduino listens on the serial port for information. So yes, you can use the Windows command prompt, or anything else that will send serial data. I use Cygwin and the LSW on my system, which makes some things a little easier and some things a little tougher. In cmd.exe, there is no normal way to send "just this particular string" to the serial port. You end up needing to use set with a prompt and send the prompt to the serial port. On the linux side (LSW and Cygwin) you can just echo. Or you can use the serial monitor from the Arduino IDE, or Putty, or whatever. :)

 

Current control system:

The existing code uses a configuration array to control per fan. Eight bytes of configuration per segment, with config options split per byte and defined by the mode. (You really should take a peek at the Git code). The serial listens for '>#,#,#' where > is a hard-coded handshake, # is a human-readable uint, and , is any non-number. XD Then it splits the three as "section, item, value" and writes them to the config.

 

The thing is that the new, not-yet-released version of the code has gotten Very. Very™. Some modes got pseudo-consolidated (Why have "solid color" mode when having both sides of "Split color" mode be the same color is the same thing?) and some modes have configuration options that HUGELY affect how the modes look. O.O Plus since each fan can be addressed individually, there's a crapton of capability there.

 

However, yes, you could potentially store multiple arrays, or change the code to address less granularly and change things with a button on the fly.

 

Memory:

The Arduino has three segments of memory:

Flash -> Static memory used to store the "firmware" code itself. Writable about 10k times, all at a time.

SRAM -> Main dynamic memory. 2560 bytes.

EEPROM -> "Storage" - Readable and Writable by the firmware. Writable over 100k times. 1024 bytes.

 

The existing code on Git has the firmware use default on startup.

The new code saves to the EEPROM on demand and loads at startup and on demand.

 

My wife would like to assure your wife that the hardware portion was a whopping hour and 40 minutes when I was arguing with a video camera at the same time and was a half hour when I didn't video things. The code is a bit more time though if you poke it a lot. If she can convince you to stick with the Serial control and not poke buttons, it'll help. XD

Memory:

The Arduino has three segments of memory:

Flash -> Static memory used to store the "firmware" code itself. Writable about 10k times, all at a time.

SRAM -> Main dynamic memory. 2560 bytes.

EEPROM -> "Storage" - Readable and Writable by the firmware. Writable over 100k times. 1024 bytes.

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.

 

The code is a bit more time though if you poke it a lot. If she can convince you to stick with the Serial control and not poke buttons, it'll help. XD

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.

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.

 

Sorry, I should clarify:

Firmware program machine code goes in flash, which is 28,672 byes.

 

The new code on my side has increased from 11,736 bytes compiled to 17,254 bytes compiled. I've been trying to do occasional optimization on it via manual brute force changes. It's interesting what things affect compiled code size. However AVRs tend to be tricky. Technically you could code for the ARM that the LNP uses, but the toolchain for that and supply of easy libraries is lacking.

 

I've dropped the current test code onto a new branch on Git for you to see what's up. Branch controller-0.2.0

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

Best of luck with the Delidding.

 

The code is fully compiled to machine code. In fact, the FastLED library contains a large number of ASM chunks handed to the compiler. The end result is pure AVR RISC instruction set machine code. ^.^

 

The LNP (Yes, lighting node pro) is definitely not required. It's just an ARM processor with 128K of program space and 8k of EEPROM. *shrug*

 

Now, on my side, I get to have a bunch of not-fun with the fact that Cygwin opens the serial port at 1200 baud and stty won't work on the USB virtual serial port. :\ Gah.

Muahahahahaha! Next Version demo video made!

[ame]

[/ame]

Muahahahahaha! Next Version demo video made!

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

XD

 

Yeah, that was 12 hours of hand-sequencing to make that. Not at all something I'd leave running all the time. Especially since the demo specifically plays the music on the computer too (was for timing purposes). So also not something I'd make more of.

 

Married with fuill time work and cats here, so I understand the time crunches. Plus the cats enjoy being "helpful" with wires. This generally involves chewing them to bits.

Now that I've read up a bunch on the board, and the source, etc.. I have a few more questions. ;)

 

--- Ground to GND, +5 to RAW (Since power will be coming -in- on the cable), Data to Pin 3

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

RAW is the unregulated voltage input for the Pro Micro. If the board is powered via USB, the voltage at this pin will be about 4.8V (USB’s 5V minus a schottkey diode drop). On the other hand, if the board is powered externally, through this pin, the applied voltage can be up to 12V.

 

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

 

There is no "plug detection". No way to know whether a port has a fan plugged in. So any custom control needs to be specifically set to have the correct number for the fans that you have, or 72 max.

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

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

 

Is it absolutely necessary? No. Is it a Good Idea? Probably. The 5V from the hub to the controller are technically both the same rail from the PSU, just coming from separate places. However if the USB disconnects for whatever reason, resets, etc, the 5V from the hub will keep everything running.

 

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

 

Yes, but probably not really.

It's a cascade and latch system when it reaches the strip. Starting from nothing, the data reaches the first LED and is stored on it. The next one-LED segment of data is stored and the prior one is spat out to the next LED. When there is a long enough pause in the data stream, the LEDs will "latch" and start PWN-displaying the set data.

 

If there are three LEDs, FastLED sends #3 data to the strip, which gets stored on LED 1. Then it sends #2, and LED #1 spits the #3 data to #2 while it takes data for #2. Then it sends #1 and it gets bumped along so #2 sends the #3 data to #3, #1 sends #2 data to #2, and #1 gets its data. Then a "long" (5000 picoseconds or so, give or take a magnitude) pause causes them to stop listening for data and start displaying the results.

 

There is no concept of LEDs knowing which one they are and FastLED has to send the whole set every time it does anything at all. So sending the data back to FastLED would just end up giving the data back at the end. That being said, -technically- it might be possible to say "I started hearing incoming data after sending N segments of data, so I must have N LEDs attached in the loop". That would be VERY non-trivial however. ^.^

 

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

 

The timer idea would be a possibility.

 

As for Temp/Tach, I'm perhaps a weirdo on that matter. My super-fancy LED colors in my opinion should show me pretty things, not "Stay one color when everything is proper (cool) and change to a bad color that I hope to never see when things turn bad (hot)." I prefer interesting feedback over temp colors, since if things are going well, you would only ever see one color, or you'd end up desensitized to it from the fluctuations, or if it shows OMG colors, well, you have bigger things to worry about than pretty LEDs. :)

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.

Pin 3 is the default because 1 and 2 are used for hardware serial on most Arduino boards and 3 is just the first available digital pin. 3 is not mandatory.

 

That being said, interrupts are disabled, which means they will not fire. They are not delayed, they are fully dropped.

 

However, as in any hardware interrupt situation, the source of the interrupt is important too. Edge or state? But this also adds complexity...

 

If the interrupt is on the edge, it will not fire at all unless it occurs when the interrupts are enabled. If it's on the state, it will fire repeatedly until the state is lost. So most interrupts are edge interrupts (the pin changes from high to low or vice versa, rather than the pin -is- high or low).

 

To be sure, I'd just track the pin state with a static, watch for a change, and then continue watching/ignoring until it changes again to reset.

That being said, interrupts are disabled, which means they will not fire. They are not delayed, they are fully dropped.

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)

Writing out WS2812 data requires some pretty tight timing. Tight enough that FastLED disables interrupts while it is writing out led data. This means that while the led data is being written out, any interrupts that happen will be delayed until all the led data is written out.

(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

Interesting. I think that may primarily have to do with the serial offloading interupt. As long as there is any data in the hardware serial, it will continue to fire that interrupt. Normally a separate chip and a one-byte buffer on that chip, that then gets transferred to internal memory on the AVR by the serial handler. So that would be "delayed" in the sense that the interrupt will continue to fire as long as there is data.

 

On the pins, there are two hardware interrupts that can be set to either edge or to low state. A state change should fire only once and be ignored if interrupts are off, and a low should fire repeatedly until it goes high again. The question of whether edge interrupts are delayed or dropped is not one easily searched for on Google, so let us know.