The Corsair User Forums  

Go Back   The Corsair User Forums > Corsair Enthusiasts Section > System Builds, Modding, Custom Components, and Picture Gallery

Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old 01-14-2017, 07:44 PM
Charixfox Charixfox is offline
Doer of Things and Stuff
Charixfox's PC Specs
 
Join Date: Oct 2015
Posts: 254
POST ID # = 886692
Charixfox Reputation: 19
Lightbulb HD120 RGB Software Custom Lighting Controller - Work in Progress

DISCLAIMERS
This is currently a DO IT YOURSELF project working with low voltage and sensitive electronics. This is not in any way endorsed by Corsair and will probably void the living bajeebers out of your warranty. And the dead bajeebers too.

In the current state, some knowledge of electrical work and safety is necessary.

In short: Know stuff or you might break things, including yourself.

THIS IS NOT PLUG AND PLAY.

Onward!
October 11, 2019 Update
After not committing any code for all this time, I am sunsetting this project. The code will remain available for anybody who wants to use it or improve on it. I may pick it back up in the future (would that make it a new day?) but at this point I do not foresee doing so now that Corsair has capable controllers available in retail.

I applaud the folks at Corsair for coming out with a highly-capable controller. After hearing from somebody who worked there and went on to become my coworker afterward ("Wait, YOU'RE Kitdragon?!"), I'm happy I was able to provide inspiration to your teams for the project. Keep up the awesome work, design cool new things, and have fun!

January 4, 2018 Update
The thread is getting Very Long, so this portion consolidates some of the information.
  • The project should use a "Leonardo" style Arduino. The chip on that kind of board has integrated UART handling and will not drop serial information. While other Arduino boards may work, if you encounter problems with them, I will simply advise you to use a supported board. Appropriate boards are, for example, the Pro Micro or Beetle board, basically anything sporting an ATMega32u4 AVR.
  • You (currently) will need to know how to compile and upload sketches to the Arduino. Knowing how to do small (or large) changes to sketches is also strongly recommended.
  • The firmware I developed is located at https://github.com/Charixfox/HD120-Controller. Ongoing development is occurring (very) slowly.
  • The Ground and Data pins are the only pins that should be connected between the Arduino and the LED hub. Connecting the 5V is a Bad Idea with most motherboards these days.
  • There are a few PC programs that have been developed by other users on their own time to communicate with the firmware. One such is at http://forum.corsair.com/forums/show...&postcount=190 on this thread.
  • I absolutely suck at video editing, so I have not yet successfully made an instructional video.
  • If the fans light up at all, something worked right. The LEDs will not light if they get only power and no signal. Getting them to light up The way you want requires a USB connection to the computer.
  • Since this project first started, Corsair did finally come out with a few controllers that are less-sucky. The Lighting Node Pro and Commander Pro work with Link to do blinkenlights.
  • No, I will not ever support or advocate "Temperature-based lighting" for one very simple reason: This project is meant to have INTERESTING, FLASHY lighting. Like RGB Overload. Temperature-based colors have the following: One color. If it changes, your computer is going to die. That is not interesting or flashy. That is "Not dying" or "Dying-so-I-Don't-Want-To-See-This". This doesn't stop anybody else from making a system that will send commands to interrupt the normal operation of the lights and make them scary-colored when your computer is burning parts of itself up.
  • All of the above are mutable due to the fact that there is rarely such a thing as "Not possible" or "never" or "always". Can it be done? Maybe. Will it be worth it? Maybe. Will it be easy or difficult? Maybe.

January 30, 2017 Update
Current Status:
- I have installed an Arduino Pro Micro into the housing for the original controller and stolen the original controller's cable. This unit is a good size and has some advanced capability for future use. The Arduino is connected to the hub and to a Micro USB to Motherboard Header cable.
- Code for simple firmware for the Arduino is located at https://github.com/Charixfox/HD120-Controller and I will hopefully be able to work more on this moving forward. The person who has the fans installed in her case right now is perfectly happy with Angry Myia Mode (don't ask about the name. Just don't. It has to do with Blue Fizzies being stabbed to death) so development and testing is somewhat hindered by no longer having easy access to the hardware and I'm reluctant to invest another $90 or $180 in three to six more fans just to code more things that might never be used.
- With a small bit of effort this project -can- technically be done without solder. The structural integrity is not guaranteed however.

Bonus:
SP120 RGB fans are fan-addressable UCS1903 controller chips, so with some minor code changes, the same or similar code can be used on them.

More things coming soon!

Original information
I'm not the first person to try to figure out what's going on with the HD120 RGB fans and their beautiful LEDs, but the other person who did apparently posted asking if he could say it and then never returned. Sadness was the result.

First, the basic findings so far...

When I saw that the lighting was 12 Individually-Addressable RGB LEDs, my heart lit up and I got excited. Individually-addressable means that each one could have its own color and be at my every whim! However the basic controller that comes with it is rudimentary to say the least (when being kind to it).

I tried some searching in various places and, as usual, Google thought it was going to be smart and guessed what I meant, then fed me the most advertisingliscious results it could. And here on these forms, well, I told the story above.

Right. Time to take matters into my own hands and open up some stuff. We'll skip the mistakes I made and get right into the results. One of the things I needed to determine was what kind of LED packages were used in the lighting system. There are two common Digitally-Individually-Addressable (DIA) LED systems that exist today, so I hoped that it would be one of those. The two are WS2812 (which is a single SMC package that contains a WS2811 controller and RGB LEDs in one package) and APA102.

The normal Controller for this fan set has two parts: The hub that six fans and the "remote" module plug into, and the remote module that has buttons on it to change the Mode, Color, and Speed.

The fan itself has two separate 4-Pin IIC female connectors. One is a normal double-thick block 4-Pin PWM 12V fan connector. The other is a clip-bearing 4-Pin LED Lighting connector.

IMPORTANT:
The fan works on 12V PWM.
The LEDs work on 5V and single-line digital serial.

The fact that there were four pins instead of six combined with the "You must connect the fans to the ports in order for the lights to all work" to tell me that the candidate was WS2812. Not quite as capable as APA102s, but half the cost and less-complex.

The next bit of fun was getting into the control modules. Four screws on the hub and two on the button remote, both under the sticky pads. This contained the important information that strengthened some of my suspicions.

The hub takes +5v and Ground from the SATA connector to power the controller and the LEDs. The remote has three wires going to the hub, so either it had to be using a digital signalling to logic hardware in the hub or the logic hardware had to be in the remote. Turns out it's in the remote. One ATMEL 2mbit EEPROM and an unmarked 8-pin processor chip work with 5V and Ground and have a single line out for the digital data signal.

Each port on the hub has +5V and Ground, and then Data Out (from the hub to the fan) and Data In (From the fan to the hub so it can be passed to the next fan). The data signal from the remote is passed to Port 1 on the hub, then the Data In (I prefer to call Data Return) on the port is passed to the Data Out on the next port, and so on through all six.

Pinout for the LED connector on the fan -WIRES TOWARDS YOU, CLIP FACING UP-:
Ground Data Out Data Return +5V

That's part of the important part.

(This means that plugging this into a 12V PWM Fan controller will fry it like a doughnut. Mmmm... Doughnuts... Blah, now I want doughnuts.)

Next up, an Arduino Mega 2560 was loaded up with FastLED and advised that this was WS2811 Control type, 12 LEDs, and GRB. A basic "demo/test pattern" program was loaded onto the Arduino.

In summary, some wiring with pins, some resistors (for safety), a nice big capacitor (also for safety) and a 5V power supply later and...

Success! Muahahahahahahaha!

The LEDs are most likely WS2812 SMC modules and at least are communication-compatible with such.

I did note that the LED arrangement on the HD120s is... slightly evil. *Sigh*

12 LEDs can be best arranged "on the hour" or "on the half hour". These are "On the half hour", so there are three on each quarter of the ring, and consider them "In the hour" of the full hour before them. This allows the break between two colors to be on the hour.

Addressing them though, looking at the back of the fan, upright (Labeled sticker will be upright and cables come in to the upper section of the left side)...
LED 1 is at the 10:30 position. So 1 and 2 are on the upper left, followed by 3-8 on the right, going clockwise (when looking at the back, so counter-clockwise and on the left when looking at the front), then 9-12 bringing up the left and finishing at 9:30.This means programmatically aligning things in the quadrants becomes more of a pain since it isn't easily split into 1-3, 4-6, 7-9. 10-12.

Image courtesy of timr:


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.

The LEDs HAVE NO DEFAULT COLOR WHEN POWERED ON. Their default is "off", so without data, nothing!

I'm going to go ahead and try to get some video of the work here, as well as see if I can put together a full 6-fan array and get video of that.

Got questions? Ask! I'll answer if I can. ^.^

Edit April 24 2017:
Realized I should put the new version video here. This is a much-newer version than the video in the next post down. Enjoy!

Last edited by Charixfox; 10-11-2019 at 06:41 PM. Reason: Sunset October 11 2019
Reply With Quote


  #2  
Old 01-14-2017, 11:06 PM
Charixfox Charixfox is offline
Doer of Things and Stuff
Charixfox's PC Specs
 
Join Date: Oct 2015
Posts: 254
POST ID # = 886706
Charixfox Reputation: 19
Default

Video!
(Turn sound off. Sorry)
Reply With Quote


  #3  
Old 01-21-2017, 04:13 AM
Charixfox Charixfox is offline
Doer of Things and Stuff
Charixfox's PC Specs
 
Join Date: Oct 2015
Posts: 254
POST ID # = 887768
Charixfox Reputation: 19
Default

Next segment of progress...

I have gotten some Arduino Mini Pros (they cost about $7 each) and a Mobo header to USB Micro and made everything work on that. The original controller guts have been removed from the plastic housing and after a few small bits of plastic coming out to make space and some soldering on the board (I really should have put some strain relief on it, so hopefully I won't move it around too much inside the system) I now have a little controller box with only one screw out of two (ahh well) and a USB connection instead of working buttons. :)

It can technically run one fan's lights off USB power alone if I keep the intensity limited to 37.5% (96/256 brightness) but can't run two unless I reduce the brightness to about 30% (76/256). The SATA power connector -must- be connected and powered up first if more than 500mA of power is drawn or it'll very happily fry the controller board from trying to power too many lights from the USB. No way around that that I know of unfortunately. T^T )

Next comes some coding into the controller to make it Do Things. I'm making use of the FastLED library and will be using normal serial connections to the computer at the moment for control. This means no "User Friendly" control method yet unfortunately. In the future I might explore Node-Pixel but the idea of a web page controlling the case lighting is actually kind of creepy. <.<
Reply With Quote


  #4  
Old 01-21-2017, 05:03 AM
red-ray red-ray is offline
Banned
red-ray's PC Specs
 
Join Date: May 2014
Location: England (GMT+1)
Posts: 7,152
POST ID # = 887774
red-ray Reputation: 81
Excited What would I need too get?

Quote:
Originally Posted by Charixfox View Post
if more than 500mA of power is drawn
USB 3.0 can supply 900ma and maybe you can tell you are connected to a USB 3.0 port.

I guess I should get the bits and then get SIV to talk to it. What do I need and how would I download your firmware?
Reply With Quote


  #5  
Old 01-21-2017, 04:37 PM
Charixfox Charixfox is offline
Doer of Things and Stuff
Charixfox's PC Specs
 
Join Date: Oct 2015
Posts: 254
POST ID # = 887861
Charixfox Reputation: 19
Default

Quote:
Originally Posted by red-ray View Post
USB 3.0 can supply 900ma and maybe you can tell you are connected to a USB 3.0 port.
500mA draw off the USB port is a limitation of the Arduino, not the USB port.

Just to put things in perspective, each LED at full brightness will draw 60mA, so one fan at full brightness, full white would be 720mA. Six fans at bright white would be 4,320mA, and even those 3A "Super-Power USB" ports would be overloaded.

Quote:
Originally Posted by red-ray View Post
I guess I should get the bits and then get SIV to talk to it. What do I need and how would I download your firmware?
Parts-wise in use:
- Kookye Micro Pro Arduino clone (Amazon or other supplier)
- Three blobs of solder to connect the three-wire cable that I cannibalized from the original controller
--- Ground to GND, +5 to RAW (Since power will be coming -in- on the cable), Data to Pin 3

Firmware-wise isn't fully developed yet. I've only run the "100-line demo" code from the FastLED examples. I'm still trying to decide how to best do this. So you'd need the Arduino IDE (from arduino.cc, not arduino.org) and use the library manager to install the FastLED library.

I have to test a thing that might correct the odd LED mapping and if it works (It would be using an undocumented behavior of the FastLED library) then I'll have some good info.

I had two options on the main loop on the controller:
1: Autonomous.
- Check for serial data for wake and send ACK if got wake
-- Receive new directions and modified stored flags
- Use stored flags or Progmen default to change LED values.
- Remap the stupid alignment (if possible - still haven't checked)
- Display the things and go back to the top.

2: 100% Software Controlled
- Wait for monolithic packet of LED data because the computer does all the fancy calculations and just sends a string of data over serial
-- If the packet isn't broken, put it into the pixel data.
- Display the things and go back to the top
Reply With Quote


  #6  
Old 04-24-2017, 12:26 AM
garyd9 garyd9 is offline
Registered User
garyd9's PC Specs
 
Join Date: Apr 2017
Location: Pittsburgh, PA (USA)
Posts: 36
POST ID # = 900462
garyd9 Reputation: 10
Default

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

Quote:
Originally Posted by Charixfox View Post
--- 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
Quote:
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.)

Quote:
Originally Posted by Charixfox View Post
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
Reply With Quote


  #7  
Old 04-24-2017, 12:47 AM
Charixfox Charixfox is offline
Doer of Things and Stuff
Charixfox's PC Specs
 
Join Date: Oct 2015
Posts: 254
POST ID # = 900465
Charixfox Reputation: 19
Default

Quote:
Originally Posted by garyd9 View Post
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.

Quote:
Originally Posted by garyd9 View Post
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. ^.^

Quote:
Originally Posted by garyd9 View Post
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. :)
Reply With Quote


  #8  
Old 01-21-2017, 06:05 PM
red-ray red-ray is offline
Banned
red-ray's PC Specs
 
Join Date: May 2014
Location: England (GMT+1)
Posts: 7,152
POST ID # = 887866
red-ray Reputation: 81
Idea I guess I should get a couple, plug them in and look

Thank you for the information. I think the sensible option is to power the LEDs from the SATA connector as they are by default.

What device does Windows see this as? Is http://www.ebay.co.uk/itm/141962370191 what I need? I guess I should get a couple, plug them in and look.

I was hoping for a HID device and ideally I would send the usual 64 byte HID packet with RGB values for the LEDs I wished to change. I was thinking in terms of a 4 byte header:
  1. Protocol Version - 0x10 - V1.0
  2. Reserved or maybe checksum
  3. Packet type - 1 set LED colours
  4. Count of per LED data blocks - 1 to 15 though I suspect I would only send up to 12.
and then up to 15 x 4 byte per LED data blocks:
  1. LED index (0 to 71)
  2. LED Red Value
  3. LED Green Value
  4. LED Blue Value
I just got the IDE from https://www.arduino.cc/en/Main/Software

Last edited by red-ray; 01-21-2017 at 06:26 PM. Reason: just got the IDE
Reply With Quote


  #9  
Old 01-21-2017, 08:04 PM
Charixfox Charixfox is offline
Doer of Things and Stuff
Charixfox's PC Specs
 
Join Date: Oct 2015
Posts: 254
POST ID # = 887873
Charixfox Reputation: 19
Default

IIRC, the PWM is out of phase so alternates between colors, since there is a similar thing that is sold that uses the same LEDs in a 30-LED strip and runs wholly off USB.

Yes, that EBay listing is precisely what I got off Amazon. In my case, it was Amazon US and five of them for $28.

And yes, it looks like they might be able to be HID.
Reply With Quote


  #10  
Old 01-21-2017, 09:46 PM
Charixfox Charixfox is offline
Doer of Things and Stuff
Charixfox's PC Specs
 
Join Date: Oct 2015
Posts: 254
POST ID # = 887881
Charixfox Reputation: 19
Default

Perhaps rather than using four bytes per LED, perhaps have a fan ID (offest = fanID * 12 on the controller side) followed by plain old 3-byte 0-11. This allows you to not spend as much transfer and address only fans that you want to change, though you can't fit two fans into the mix.

One very important thing to consider is that when writing out to the LEDs, IIRC the controller will drop all data sent to it while it turns off interrupts to write out, so do keep that in mind.
Reply With Quote


  #11  
Old 01-22-2017, 04:04 AM
red-ray red-ray is offline
Banned
red-ray's PC Specs
 
Join Date: May 2014
Location: England (GMT+1)
Posts: 7,152
POST ID # = 887902
red-ray Reputation: 81
Thumbs up Thank you for confirming the link.

Assuming we can make the device HID then the transfer rate should be 12Mb/sec so saving the odd byte in a packet has little benefit. I also suspect I will wish each LED to be a different colour so as things get hotter more and more LEDs will change from say Blue to Green to Red.

To deal with interrupts being disabled I am inclined towards:
  1. Receive the setup packet
  2. Disable Interrupts
  3. Write to the LEDs
  4. Enable Interrupts
  5. Send a success/fail packet.
It's also possible if we can use HID rather than virtual COM port there will not be a data overrun issue at all.

I would also like a method to request the firmware version.

I assume we could connect such as http://www.ebay.co.uk/itm/132030120812 WS2811 5050 RGB LEDs or http://www.ebay.co.uk/itm/262559814200 WS2812B 5050 RGB LEDs, am I correct and which one?

I adjusted the SIV code and most of the support is now there. To test it I used a Corsair Link PMBus Bridge (old Link Commander) to pretend to be the Micro Pro Arduino. I found one device with 72 fans to be cumbersome, so I presented it as 6 fans each with 12 LEDs. All I need now is some hardware to arrive and some firmware.
Attached Images
File Type: png [Link Status] for HD Fan LEDs.png (79.1 KB, 1516 views)
File Type: png [Link LEDs] for HD Fan LED control.png (56.5 KB, 2533 views)

Last edited by red-ray; 01-30-2017 at 03:46 AM. Reason: SIV screen shots
Reply With Quote


  #12  
Old 01-22-2017, 05:28 PM
Charixfox Charixfox is offline
Doer of Things and Stuff
Charixfox's PC Specs
 
Join Date: Oct 2015
Posts: 254
POST ID # = 887947
Charixfox Reputation: 19
Default

The bottleneck will be the Arduino AVR. Tight and efficient code is important in that. Limited memory space and program space. About 27kb free for code and 2.5kb of RAM, and the processor runs at a whopping 16 MHz.

Looks like other folks have fought to make the Arduino Micro accept data from the computer on HID. The core Arduino library has the USB functionality and it normally doesn't handle PC -> Device HID. Somebody did some modifications at http://forum.arduino.cc/index.php?topic=256542.0 to get it to be otherwise.

With the FastLED library, the LED write command is a blocking command that disables interrupts, so just a plain old FastLED.show() will handle the interrupts, writing to the LEDs and then re-enabling the interrupts afterward. You could definitely do this manually if you like. Folks have determined some much simpler code to handle writing out to these kinds of LEDs that takes advantage of the wiggle room in the protocol to allow interrupts to occur if the handler is fast enough and such.

I'll have to look up the specs on the Micro. The USB handling is built into the AVR so it might not suffer from the single-byte serial buffer that others do. In retrospect, this makes the extra $2 for the Micro a better solution than the Nano as well.

Use the WS2812B when possible. The control chips are the same, but the package integrity and reliability is better. Either one would work though technically.

A chunk of my goal is to get things working for interesting lighting more than temperature indication. On a good day, temp indication lighting should be pretty boring. So things like spinners, multi-fan coordination, cross fades, possibly sound-based things or whoknowswhat. In my case, the spirit is willing, but the code is weak. <.<
Reply With Quote


  #13  
Old 01-22-2017, 06:14 PM
red-ray red-ray is offline
Banned
red-ray's PC Specs
 
Join Date: May 2014
Location: England (GMT+1)
Posts: 7,152
POST ID # = 887949
red-ray Reputation: 81
Default

Thank you for the information. I will have a look once the hardware arrives.

I suspect writing my own firmware will be easy enough once I get into it.
Reply With Quote


  #14  
Old 01-22-2017, 06:26 PM
Charixfox Charixfox is offline
Doer of Things and Stuff
Charixfox's PC Specs
 
Join Date: Oct 2015
Posts: 254
POST ID # = 887950
Charixfox Reputation: 19
Default

Quote:
Originally Posted by red-ray View Post
I suspect writing my own firmware will be easy enough once I get into it.
Very likely. It's all just C++ with some interesting libraries and hardware. In the IDE, set the target board as a Leonardo.
Reply With Quote


  #15  
Old 01-25-2017, 11:17 AM
red-ray red-ray is offline
Banned
red-ray's PC Specs
 
Join Date: May 2014
Location: England (GMT+1)
Posts: 7,152
POST ID # = 888322
red-ray Reputation: 81
Question Where did you get the Windows driver from please?

Where did you get the Windows driver from please? Thus far I have not found one for Windows 7 x64 SP1 or any other version of Windows. I tried as per https://www.arduino.cc/en/Guide/DriverInstallation with no luck. Does dism /online /get-drivers /format:table list any Arduino drivers and if so what is the .INF file called.

When I plugged the device in I checked the USB interface descriptors' with SIV and it has a HID one . Do you devices report the same interfaces?

The USB firmware is slightly dodgy and I suspect would fail https://msdn.microsoft.com/en-gb/lib...(v=vs.85).aspx. This is all too common and my H80iGT Cooler is similar.

Quote:
Attached Images
File Type: png Arduino Leonardo.png (76.7 KB, 24802 views)

Last edited by red-ray; 01-25-2017 at 11:45 AM.
Reply With Quote


Reply

Tags
hd120 rgb

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -4. The time now is 09:48 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2020, vBulletin Solutions, Inc.