Summer Project: "Fanbus" Digital PC fan and LED System

[CalcProgrammer1]

You may remember my previous project from early this year, the RGB LED Fan Controller. It is a custom fan controller I built that not only has digital, software controlled fan speed and RPM feedback but also four color-changing LED's that allow you to manually set the colors or cycle them using a program (or even make them flash different colors to music with a special app).

Well, I just built my new i7 build and going back to plain old blue LED's is getting boring. The Antec Nine Hundred case has four 120MM fans that are all within plain sight so just swapping one fan is hardly an option, but building four of my original fan controllers will require four serial ports and a lot of room to mount the boards.

The solution? A new, smaller design that simplifies multiple devices using daisy-chaining style connections. I will design a smaller RGB Fan Controller board using surface mount components that can be glued or otherwise directly attached to the fan, minimizing cable clutter. A single cable carries power and data to the fan and two ports per fan means that you can string them together in a chain. I will also design an LED controller that uses extra RGB LED's to shine onto the motherboard and PC components visible through the side window. All of these devices will connect to a "master" controller, which will connect to the PC using either serial or USB. The master controller may either be a small board that does nothing but interface, or it may be built into a front panel with an LCD display and digital knobs. This will allow the fans to be controlled either by software on the PC or front mounted knobs.

To simplify the interconnects, I plan to learn how to use the I2C interface to communicate between the master and slave devices.

This is just an idea I've been thinking about for the past few days, but I think it would be a very clean and professional way to connect case accessories and fans, and if I do it right the software shouldn't be terribly difficult either. Would anyone be interested in a system like this? I'm not doing this for money but I'd like to know what people think of the idea.

 

[Granyte]

i can't see your picture but your project is quite interesting it's actualy your original projet wich brought me here on these forum cause for sumer time i plan on building a custom back cover to help air flow in my alienware M17 and i hope to build it with your methode as it would alow me to have a nice efect that fit with the rest of my lappy and at the same time if you add suport for aditional led it could help me correct th fact that the m17 head only light blue

the only draw back at the moment is that most modern laptop don't have a serial port mine is no exception it got everything but that

 

[CalcProgrammer1]

If you're really good with soldering you can usually cram USB devices into open spaces in laptops. I haven't tried it but I've seen other people do it, find the USB connections on the motherboard and use it with the circuit board from a USB to serial adapter. If that doesn't work you can try the V-USB firmware for AVR microcontrollers, it allows you to directly do USB communications at low speed.

 

[Granyte]

i have next to no experience with soldering so soldering onto a pcb i made up my self is one thing but soldering onto my 3k lappy mobo .... and doing so what would be the modification done to your original project ? just soldering a usb cable instead of a serial one

also one last thing does your answer mean that you don't plan on pursuiing the project of making a new version that would suport more led and potentily aditional fans?

 

[CalcProgrammer1]

Time to revive this old thread, since I had no time during the summer due to work, I now have time at school and I got some new stuff to play with

Using the ATMega168 chip (same one I used before) I'm working up a master and slave configuration using the Philips i2c protocol (known as TWI - Two Wire Interface in Atmel's references). i2c is a common protocol which supports individual addressing of up to 128 devices with bi-directional communication using just 2 wires (SDA and SCL, a data line and a clock line). I spent quite a bit of time getting Atmel's provided demo code for the TWI module working but finally have solid communication between two microcontrollers so it's time to start working on my new fan controllers.

I also got a 2x16 character LCD module that is really simple to use. It would make a nice front-panel interface with a knob or some buttons. Now I need to port all my existing RGB Fan Controller code to using the i2c interface and write a new master code to convert serial data from the PC to i2c data for the fans as well as drive the LCD and any onboard functionality I want to add.

 

[Granyte]

nice to know i've been experimenting with the ATMega 328 recently (inside the arduino platform) bu i'm having a **** of a hard time to manage a serial com capable of transmiting all the datas i need

 

[CalcProgrammer1]

Continuing with the i2c communications, I am trying to develop a self-addressing system where the master assigns each connected device an address (rather than programming each device manually). If the devices are chained linearly and wires do not branch, I should be able to use a third wire to enable devices individually. The master "turns on" the first device and gives it the first address, then the first device turns on the second and the master assigns the second device the second address and so on until the master receives no acknowledgement indicating that no more devices exist. This seems like a pretty simple idea and I have some untested code written for it.

As for Arduino serial communication, it's simple. Serial.begin(<baud rate>) to start, Serial.Available() to check if there's new bytes, and Serial.read() (I think) to read in byte by byte. The harder part is creating a protocol (a formatting style) that allows you to transmit different commands. A simple protocol can be a 2-byte protocol, for instance <command byte> <data byte> where command tells the Arduino what to do and data is the data to perform the action with (for instance, if you're setting two lights, the command picks between the two lights and the data is the desired brightness level). However, I quickly found that a 2 byte system can fail if the Arduino misses a byte. If this should happen it is now out of sync and your data is interpreted as command and command as data, producing undesirable results. To counter this, I use "start" and "stop" bytes in a 4-byte format protocol. A known start byte starts the communication, then the command and data bytes, and then a known stop byte. If the first byte is different than the known start byte (or the stop byte is different from the known stop byte) then the packet has errors and is discarded.

In simple pseudocode, here is what I mean, this is essentially how my fan controller code reads the serial data:

do
{
//read and store latest serial byte
}while( latest byte is not the known start byte )
for(0 to 2)
{
//save 3 bytes
}
if( last byte is equal to known stop byte )
{
//proceed with operation on second and third bytes
}
else
{
//error, stop byte was incorrectly received
}

 

[S0ULphIRE]

Sounds good, bring on the project

 

[Granyte]

thanks your pseudo code is helping much more then most of what i could find initiating the serial comm was not that hard but getting the protocol to work .....

and when you end up having several datas that might changes at the same time i will need more work on my c++ skills....

and keep up the good work i hope to see your project's result