Another day, another project started. I have a nice 5-meter LED strip in the office, which provides indirect lighting at Jee Labs. Works fine, but despite being called “warm white”, it’s slightly greenish. Not so great…
Someone suggested adding an RGB strip next to it, to compensate for the color.
So to start off this multi-part series, I wanted to simply control RGB. This is very easy to do with three MOSFETs. I used IRLZ34N’s N-channel, since the LED strips are common anode. The circuit is trivial: source to ground, drain to LED cathode, and gate to an I/O pin. Rinse and repeat three times. I didn’t even add a pull-down resistor to the gate, though I probably should.
Here’s the circuit, fully connected to a test strip with 9 RGB LEDs using a separate 12V power supply:
I wrote a little test sketch which ramps the light levels up and down using PWM, and which goes through all the RGB combinations – using some bit fiddling:
The LEDs are pulsed in software, with a cycle time of 8160 µsec (32 * 255), i.e. roughly 120 Hz. No discernible flickering. A more advanced version ought to use interrupts to keep the PWM going in the background.
Here’s a video of the result – with apologies for the very low quality.
Since the JeeNode has RF on board, it will only be a small step to add wireless control. Stay tuned…
Update – Source and drain were listed the wrong way around, I’ve updated the text above.
Does this mean you can get virtually every color from the RGB strip?
The strips I have came with a controller & 433Mhz wireless remote that let’s me choose some colors & brightness, but I can’t control the exact color though…
Yes: 255 brightness levels for each of R, G, and B = 24-bit colorspace.
That’s a lot of color choices indeed!
Are you also planning to use some kind of standard remote (868 / 433Mhz) that let’s you choose the RGB strip before choosing color / pattern / brightness??
The remotes I have now interfere with each other due to their very good 433Mhz range and I don’t seem to be able to select some kind of address orso…
BTW: I’m using these remotes:
Grrrrrrr. No pictures possible? http://imgs.inkfrog.com/pix/ledworld2007/6KEY_CONTROLLER_RF.jpg
Grrrrrrr2. Post wasn’t ready yet:
This infrared thingy: http://imgs.inkfrog.com/pix/ledworld2007/44key_controller.jpg has some DIY keys, that should make RGB strip selections possible.
Imagine a few interconnected JeeNode’s with an infrared eye, and just one remote like this one: point at any JeeNode, select the RGB strip, and set color/brightness etc. The JeeNode that receives the commands will redirect them to the proper JeeNode…
Only problem I can see if more than 1 JeeNode receives the commands like brigthness up/down in which case everything goes twice or tripple as fast up/down as intended ;-)
There are many ways to do this. Frankly, I’d rather work on making it simpler for you to pick any of a number of approaches and adapt it to your specific needs, than to work out a specific case.
Right now, I don’t have much need for elaborate control and use of all the possible colors. Maybe one day I’ll implement some features such as slowly turning on when the motion sensor triggers (if it’s dark), or adjusting the white balance to mimic the natural change of light during the day.
Using an existing IR handheld transmitter sounds like a nice idea. I would like to go more into IR (both send and recv) in the near future.
The bit that interests me is how to create an organic and flexible infrastructure for a heterogenous network – with IR, OOK, RF12, WiFi, and Ethernet in a range of combinations and topologies. With events and triggers across the whole soup, while dealing with different needs for responsiveness, reliability, security – across all the different parts involved. Should it all be centralized? Perhaps, or perhaps only partly. Is the human body centralized? Yes, partly…
The heterogenous network – with IR, OOK, RF12, WiFi, and Ethernet in a range of combinations and topologies you’re talking about (includng events/triggers etc.) sounds very much like the goal of the xPL framework where any member (sensor/actor or whatever) in the network can receive and act upon any other member’s data ;-)
Data is send using a broadcast, ie you DO receive again the data you just send (the framework should block that btw)…
To implement xPL on the ATmega might be a bit too much, but to implement the broadcast mechanism shouldn’t be too hard, nor extending the RF12 code to support a filter (internal subscribe/unsubscribe mechanism) to have data from other sensors (or whatever) coming in.
The hard part might be to set a standard for communication like sensor addressing, sensor types, values etc. in which the xPL framework ideas might be a very nice example to start with…
Would be very nice to add a JeeNode with 433Mhz receiver, and some 433Mhz transmitters, and suddenly all the data from those 433Mhz transmitters is available for ALL the other JeeNodes! Just subscribe to the OutsideTemperature sensor with id 0308 and that’s it!
Logging could be centralized (including a webserver of some kind), but actions could be decentralized easily.
The future is YOURS!
Thanks for this info – this is really interesting stuff. As with so many things, just about everything that can be done has already be done before. I will look into xPL at my leisure.
I’ve got some ideas on standards for communication and data interchange – but that’s just one facet of the bigger picture, of course.
Great!
You don’t have to let the JeeNodes ‘talk’ xPL. xPL assumes all devices are connected to a LAN, ie have a TCP/IP and UDP connection.
Other devices / network of devices (like JeeNodes) might use their own simple schema, and use a ‘bridge’ (say the JeeLink) to connect this network to a PC/LAN and make it xPL compatible.
And you’re right about the com/data xchange: If you can get a common device interchange, xPL is ‘just’ the next step, but already gives JeeNodes so much more possible functionality and easier usage!
Grrr. It happened again. I was still typing and suddenly my reply got posted again. Weird…
I once had a nice sensor network going, but managed to misplace the code for that, so that’s a pitty, since that code I wanted to use for my own JeeNodes.
However, it was not that sophisticated: the device/sensor address was just the nodenumber (1-254, 0 = illegal, 255 = broadcast) & the sensor number (0-255) in that node. Furthermore simply two bytes for the type of sensor (type/subtype) and then 1 or more values, depending on the sensortype. Messageformat was variable including message size bytes to detect errors/overflows.
One variation was to add DeviceNames to each sensor. Used more space, needed more parsing, but was sometimes more elegant and any node could request the Device by name without knowing the address. Just the device names had to be unique.
By enabling every sensor/device to be published on the network you could control anything from anywhere as the xPL add-in for Microsoft Media Center shows: you can control the TV stations, see what’s currently watched, start a movie, etc….
So, you could have other JeeNodes behave differently depending on the color of the RGB Strip, or have the RGB strip change color depending on daytime, or….. (the possibilities are becoming endless, and I could go on for ever, so I will stop for now!).