HowTo: HD120 RGB Custom Lighting Controller

[garyd9]

Originally Posted by Charixfox

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.

Originally Posted by Charixfox

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

Originally Posted by Charixfox

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

Originally Posted by Charixfox

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

Originally Posted by Charixfox

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

Originally Posted by Charixfox

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

[Charixfox]

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/embe...uino-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

[garyd9]

Originally Posted by Charixfox

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.

Originally Posted by Charixfox

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.

[Charixfox]

Originally Posted by garyd9

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

[garyd9]

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

[Charixfox]

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.

[Charixfox]

Muahahahahaha! Next Version demo video made!

YouTube (Short URL)

[garyd9]

Originally Posted by Charixfox

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

[Charixfox]

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.

[garyd9]

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

Originally Posted by Charixfox

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

Originally Posted by Charixfox

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

[Charixfox]

Originally Posted by garyd9

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

Originally Posted by garyd9

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

Originally Posted by garyd9

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

[garyd9]

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.

[Charixfox]

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.

[garyd9]

Originally Posted by Charixfox

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/w...rrupt-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

[Charixfox]

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.