100 Watt RGB LED Lamp

Since I’ve been working on this project for about a year and a half, and my motivation has continued to hold up, I think it’s time I wrote a bit about it.  Understand as you’re reading this that there have been many dead ends along the way (I haven’t written about most of them here) as I tried to figure out how to accomplish this well-beyond-my-abilities project.  I’ve learned an incredible amount along the way, which is as every bit as important to me as the finished project.

The Beginning

It all started with a piece of metal I found in a Vancouver antique shop, in mid 2012.

brass-bearing-cage

I think it’s made of bronze.  I’m pretty sure it’s a bearing cage (see the yellow bit in the 2nd diagram), possibly from a ship of some sort, since bronze is highly resistant to corrosion from salt water.  According to Wikipedia:

Bronze was especially suitable for use in boat and ship fittings prior to the wide employment of stainless steel owing to its combination of toughness and resistance to salt water corrosion. Bronze is still commonly used in ship propellers and submerged bearings.

I saw a few of these in an antique store, and immediately thought they would make a great lamp.  It turned out they weren’t really for sale, but I pleaded with the owner a bit, and they named a price.  Once I had the idea of a lamp, I couldn’t let them go!

Originally, I had planned to have the small one sit inside the big one and rotate, with LEDs inside the inner one.  Over the months, as the idea for the lamp matured in my head, I decided not to use the small one at all, scrap the idea of having anything that rotates, and “just” try to make a colour changing lamp that was capable of being as bright as a 100w incandescent bulb.  Inside each of the “windows” in the bronze would sit a single RGB LED.  Each LED would be independently controllable, so each could be a different colour.  This would allow for neat effects, such as the whole lamp being a nice warm white colour, with a green light that “spins” around a few times when I get an email. Or whole lamp could tint red for a moment late at night as a reminder that I should probably go to bed.

Well, a year and a half later, “just” doing that has turned out to be much, much harder than I originally expected.  I knew the project would take me at least a year, but the learning curve for dealing with that much power, and individually changeable RGB LEDs, was way steeper than I imagined. I’ve persevered though, making progress here and there, as time and money permits, and one day I hope to finish building the coolest lamp ever.  I have no idea what I’m going to call it though, so I’m open to suggestions.

Visual

The visual concept is basically naval, though some people have said it has a bit of a steampunk aesthetic to it.  The brass ring will be the focus, with the LEDs in the “windows”.  I hope to fashion lightly-frosted glass rings to mount in the windows with the LEDs behind them.

Below the ring will be a piece of turned wood.  I’m still trying to decide what kind of hardwood to use, and what colour to have it stained.  Since wood turning is an art of it’s own, one I don’t have the inclination (not to mention space) to learn, I’ll be hiring someone from the local woodturners guild (I had no idea such a thing existed!) to do it.  Since this is one of the few projects I’ve done that is actually going to belong to me when it’s done (most are gifts), I’m hoping to do something “personalized” for the turned wood, and use my face for the profile of the wood, like a Rubin vase.  It will be partially hollow, to make room for the electronics, and to take air in from the bottom for cooling.

On top of the bronze, I’m still not entirely sure what I’ll do.  I would like to use another piece of turned wood, but it depends a lot on how much heat the lamp produces.  I’m hoping that the large bronze piece will provide sufficient area to radiate the heat produced by the LEDs and power conversion. If it doesn’t, I’ll need a heatsink or hot air outlets above the bronze.  I would like to avoid noise, so using a fan will be last resort.  Hopefully convection will be sufficient, but I have a lot of designing and testing different heatsink arrangements to do before I’ll know.  I won’t even know how much heat the whole thing generates until I have it all wired up on my workbench for testing.

100 Watts of LED Power

I spent some time researching lumens, candela, and LED efficiency, and testing out a few different LEDs, trying to find out what I would need to have 12 RGB LEDs that, combined, are as bright as a 100 watt incandescent bulb.  I know that a 100 watt bulb is around 1800 lumens, but I don’t know how to take the “luminous flux” of the red, green, and blue LEDs that make up RGB LEDs, and calculate the lumens of white light it will product.  Since I couldn’t figure that out, I just approximated, a lot.  LEDs convert more of their electrical power to light than an incandescent bulb, and produce less heat as a result, so I think that supplying 90 watts of power to LEDs should be brighter than a 100 watt light bulb.  In the end, I think the LEDs and power supplies I’ve chosen are a bit overpowered for the job, but this means I can run them at less than peak power the vast majority of the time, which should be more efficient, and thus produce less heat.  I won’t know how bright they are until everything is hooked up, which should be happening soon, but has been a long and slow process.

The LEDs I’m currently planning to use are LED Engin 10W RGGB LEDs.  Each green LED will be running at half of what it’s rated though, so I should only be drawing about 7.5 watts.  With 12 LEDs running at that, level of power, that should be drawing around 90 watts.

Powering LEDs this powerful isn’t terribly difficult, in it’s simplest form.  However, doing so efficiently (to reduce heat) and in a small package has turned out to be a challenge.  The simple resistor method, so common in hobby electronics for small LEDs, produces a lot of heat at these power levels.  It also regulates constant(ish) voltage, not current, and constant-current regulation is what you need if you want LEDs to last a long time.  Even simple constant-current circuits using transistors product just as much heat though.  The only efficient way to regulate the current to LEDs of this power is to use a switching power supply, a constant-current buck driver.  Unfortunately, my electronics knowledge isn’t extensive enough to allow me to design and build buck drivers.  I tried.  I spent a lot of time reading, learning, and trying.  I had some fun, learned a bit, but I was never able to come up with something that worked.

Thankfully, I didn’t need to!  Just as I was getting frustrated with my inability to create a constant current buck driver, the wonderful Ethan Zonca of Protofusion designed the excellent PicoBuck, and collaborated with SparkFun to sell them.  As sold, it regulates current at 350ma, but swapping one resistor will bring that up to 700ma, which is (only just) within the tolerances of the parts used.  Armed with 12 of these, and the resistors to swap, I should be able to safely power these 12 LEDs.  The parts only just arrived recently, so I have yet to get all the soldering done and test everything.

Upstream of all this, a 192 watt AC to 12v DC adapter will be feeding power to the lamp. Having this power adapter in-line like that, rather than inside the lamp, helps move some of the heat production out to where I won’t have to deal with it.

PWM controlling the LEDs has been another interesting challenge.  After a few attempts at writing code to do bit-banging 10 or 12 bit PWM from an ATTiny85, I noticed that Adafruit had just announced a new product, a 24-channel 12-bit PWM controller.  It’s basically exactly what I was looking for, two of those should do the trick perfectly.  I need more than the standard 8 bit PWM resolution so that I have some extra resolution to use to compensate for the fact that all 12 LEDs won’t be the same brightness due to manufacturing differences.  With the extra resolution, the software should be able to do a bit of adjustment to account for this.

Peripherals

The part of the lamp that excites me the most is the peripherals.  An idea I had early on in the project was that on it’s own, the lamp wouldn’t actually do anything.  Everything would be driven by peripherals.  A processor inside the lamp will work with what I’m calling “virtual lights”, which are light sources which have a hue, saturation, brightness, and angle.  Peripherals will send commands to the processor in the lamp, to create and destroy virtual lights, and to change their angle and colour.  The lamp processor will take these virtual lights and blend them into the 12 LEDs.

For example, one peripheral might create 12 virtual lights, spaced evenly around 360 degrees, and set them to white, at some level of brightness.  The lamp would seem like just a lamp. However, another peripheral could check my email, and when it sees new emails, create a new virtual light, tell the lamp to make it red, and sweep it from 0 degrees all the way around to 359 degrees, before fading it back out.  That peripheral would not know or care that another peripheral has created the white lights.  The lamp processor would take care of blending all the virtual lights together.

An “override” feature would allow a peripheral to apply an offset to the hue, saturation, luminance, and/or angle of all virtual lights on the lamp, so that peripherals could dim the light momentarily, or perhaps slowly shift the colour towards red as the evening wears on.

The lamp will detect when peripherals are unplugged, and remove any of the virtual lights that were created by the peripheral.  This way, peripherals can be plugged in and unplugged without concern.  There will probably be some peripherals that are somewhat permanent though, that are mounted inside the lamp, rather than plugging in to the outside.  A wifi peripheral is one that would potentially be “built in” like that.

I’ve made good progress on the software for peripherals, with one demonstration video posted on YouTube.  It demonstrates quite nicely how 4 peripherals could interact, creating different coloured lights, that are blended together by the lamp.

At the moment, I’m trying to determine the electrical end of things for the peripheral bus.  My original attempt involved i2c, taking advantage of it’s multi-master ability to have peripherals send commands to the lamp processor.  However, the slow speed (maximum of 400kbit on an ATMega328, more commonly known as the microcontroller in the Arduino) of i2c wasn’t compatible with what I’m aiming for.  I would like for the lamp to be able to handle 100 virtual lights, at 60 frames per second updates, and one command per virtual light sent from peripherals every frame.  That works out to 6000 commands per second, which at 400kbit, only allows for 8 bytes per command.  They will probably fit, but that’s still a bit tight, and doesn’t even allow for the lamp’s processor to spend the time it needs blending the virtual lights, and updating the LEDs’ PWM controllers.

Instead, I’ve decided to use SPI, which allows much faster communication.  However, the requirement of the chip-select line means more pins needed on the connection to peripherals, and more pins needed from the lamp controller.  This has taken me down the path of using 74xx150 and 74xx154 chips to multiplex/demultiplex both the chip select, and the peripheral detect.  I’ll be breadboarding potential bus layouts over the next few weeks, as well as getting the LEDs all hooked up and run at full power for the first time.  It’s getting exciting. 🙂

Released: lint-maven-plugin 0.0.8

lint-maven-plugin 0.0.8 has been released, containing a bugfix, some new rules, and a few improvements.

Bugfixes:

https://github.com/lewisd32/lint-maven-plugin/issues/4

New rules (Thanks Lars):

MissingDeveloperInformationRule
MissingInceptionYearRule
MissingIssueManagementInformationRule
MissingLicenseRule
MissingUrlRule

Improvements:

Help mojo added (Thanks Lars)

Ability to specify rules to run from the command line (Thanks Lars)
eg. mvn com.lewisd:lint-maven-plugin:check -Dmaven-lint.rules=RedundantPluginVersion,RedundantDepVersion

Ability to specify in-pom rules to exclude or include.
eg. For propriatary projects, exclude all the OSS project related rules:

<plugin>
	<groupId>com.lewisd</groupId>
	<artifactId>lint-maven-plugin</artifactId>
	<version>0.0.8</version>
	<executions>
		<execution>
			<id>pom-lint</id>
			<goals>
				<goal>check</goal>
			</goals>
			<phase>verify</phase>
		</execution>
	</executions>
	<configuration>
		<rules>
			<excludes>
				<exclude>OSS*</exclude>
			</excludes>
		</rules>
	</configuration>
</plugin>

Project idea: Doomagotchi

This just randomly popped into my head today, when I saw a co-worker’s JIRA avatar was the”doom guy”.  It’s not particularly well thought out, being the result of about 2 minute’s thought.

Doomagotchi

Hardware:

  • Small OLED LCD display
  • Speaker
  • Batteries
  • 2 buttons
  • Microcontroller

Software:

  • OLED shows “doom guy” face
  • Tracks “health”, and shows correct face for health
  • Health drops slowly over time
  • Pressing one button will shoot doom guy, showing “pain” face, and decreasing health
  • Pressing other button will deliver health pack, increasing health
  • Correct sounds are played when doom guy is injured, or healed.

More ideas:

  • Maybe the midis from the game could be played sometimes too.
  • Doom guy could find health on his own, so long as the overall health trend was downwards
  • Whenever he finds health, play a sound
  • When his health is getting low, play a pain sound of some sort every now and then
  • Monsters could randomly appear on the screen, with a sound played (alternate showing the monster and doom guy, every second or so)
  • Doom guy will kill monsters on his own, but will take damage to health
  • Pressing “shoot” button will shoot whatever is on screen.  If it’s the monster will shoot monster, helping doom guy.  If it’s doom guy, will shoot doom guy.
  • Pressing “heal” button will do the same, healing whatever is on screen.

Arduino Slide Viewer Slide Show

Quite some time ago, I found an old slide viewer in an antique store, and had an idea for a neat little hack. I finally finished the hack, and I’m pretty happy with how it turned out.

Slide Viewer

I took a 1.8″ TFT LCD from Adafruit, some AAA batteries, and a couple other bits and pieces, and turned the slide viewer into a digital photo viewer that shows a slide show of photos:

Since an actual Arduino wouldn’t easily fit inside the slide viewer, I built a minimal board around the ATmega328 on some prototyping board:

Front of board

 

Back of board

All it includes is a crystal, the capacitors needed for the crystal, a resistor to hold reset high, and some header pins for various things, including the ISP pins.

Using layers of card stock glued together, I made a frame around the LCD that slots into the slide viewer:

Insert and board

The insert with the LCD and the board with the AVR chip all fit into the back of the slide viewer where the backlight used to be, and a battery pack of 3xAAA batteries fits where the original 2xC cells used to sit:

Inside of slide viewer

The slide viewer originally had contacts on the bottom that look like they allowed it to slot some sort of external power supply into it.  I’ve re-purposed that hole to mount an on/off switch, as well as a 4-pin female header block that breaks out Vcc, GND, and the I2C pins:

Bottom

I have another pair of sketches, not quite well enough polished to release yet, that turns the slide viewer into an I2C LCD, so it can be controlled from another Arduino. (If you’re interested in those sketches, leave me a comment with some contact info)

Once it’s all closed up and turned on, it displays the images on the 160×128 LCD:

The glare is much less in person, with your face close to the glass.  The images are pixelated, but certainly recognizable.

The source code is available here on Github.  This includes the Arduino sketch, and a Linux script to convert JPEG images to the required raw format.

Voyager Combadge

Last night, I surprised my girlfriend with a hand-made Voyager combadge, for our 1 year anniversary.

I’ve been working on it for the last couple weeks, telling her that the workshop is out of bounds because I’m working on a secret project.  She knew I was cooking up something for our anniversary, but she had no idea what.

Last night, at the ST:NG Season 1 Blu-ray release screening at the theatre, I presented her with this:

More photos at the Flickr set.

Vancouver Mini Maker Faire 2012

Vancouver Mini Maker Faire 2012 on the past weekend was quite the experience.  As my first time exhibiting any of my work, it was incredibly positive to see the reception it received from the attendees.  Yoda was definitely a hit with the younger crowd, with the older crowd tending to make a beeline straight for the gin lamp.

I had quite a few friends helping me at my table, so I was able to take some time to wander around, but I still missed quite a bit.  However, I was lucky enough to have Solarbotics just across the aisle from me, so I was able to chat with Jeremy there about their work with low power ATtiny chips, and share some of my experiences with low power, and estimating battery life.  They have a neat little product, the firefly, that I’m kicking myself for not getting one of when they were there.  It would seem that with the addition of a piezo and changing the firmware, it would function quite nicely as an annoyer, just like my AnnoyATtiny85 kit.  Pretty slick.

Battery life of the AnnoyATtiny85

Quite a while ago I promised a post about the battery life of the AnnoyATtiny85.  I’ve been pretty busy getting ready for Vancouver Mini Maker Faire lately, but I’m finally on the home stretch there, so I’m taking a break to finally write this post.

As you may recall from that previous post, I spent a lot of time getting the power usage of the AnnoyATtiny85 down to miniscule levels.  After all that effort, I wanted to know how long one of these devices would run for, before it became too quiet to be annoying.  Based on some rough back-of-the-envelope calculations, I discovered that the answer was on the order of many months, so I didn’t want to just leave one sitting in my apartment for months.  Instead, I programmed one with some modified code, that made it beep every 2 seconds.

Having an annoyer that should last a much shorter period of time, I decided to do some data logging, to get a good answer to my initial question.  My data logging was accomplished with a Arduino Uno connected to a Linux PC, that was simply logging the data from the serial port to a file, after prepending a timestamp to each line.  One ground pin of the Arduino was connected to the negative battery terminal of the annoyer, and two analog pins of the Arduino were connected to the positive battery pin, and the piezo beeper output pin of the annoyer.  The code on the Arduino simply read these pins a number of times every second, and wrote the output to the serial port.

After a couple hours of sitting there beeping merrily away in a corner of my workshop, I realized that it would eventually drive me mad, so I put a small piece of tape over the piezo.  I could still here it if I listened for it, but I was no longer at risk of losing my mind.  Not from that, at least.

For the next week, I would take the tape off every now and then and subjectively judge for volume of the beeping.  For the first few days, I couldn’t discern any difference between it, and a beeper with a fresh battery.  After about 5 days, it was starting to get a little bit quieter, and after 7 days, the volume had dropped enough that I could imagine it wouldn’t do a very good job of annoying anyone any more.

At this point, I had slightly over 500MB of text data recorded from my datalogger.  After running it through a few scripts, I came up with this graph:

The horizontal axis is time. The vertical axis for the red is battery voltage. The green is raw analogRead data from the buzzer pin. The faint green line at the bottom is the level read when not beeping. The range of higher readings are from when it’s beeping. (The short gap early on the 25th is when I accidentally exited the datalogger script)

One thing I found interesting is that the battery actually started at 3.1v and rapidly dropped to 2.8v, where it stayed for 16 hours before slowly beginning to drop again.  This graph zooms in on the first 18 hours of the test:

Ok, that may be pretty ant all, but what does this all tell us about the real-life battery life of this device, when it’s beeping every 5-8 minutes instead of every 2 seconds?  Let’s do the math.

For the test, the watchdog timer was set to make it start beeping every 2 seconds.  The beeps last, on average, 0.6 seconds.  This means it spends an average of 1.4 seconds idle, in deep power saving mode, between beeps.

To calculate the average current draw, we multiply 1.4 seconds by 0.007mA, the current it draws then it’s idle, and add that to 0.6 seconds times 7mA, the current it draws then it’s beeping.  We divide the whole thing by 2 seconds to get the average current draw in mA.

Test current draw:
((2s-0.6s)*0.007mA + 0.6s*7mA) / 2.0s
(1.4s*0.007mA + 0.6s*7mA) / 2.0s
(0.0098mAs + 4.2mAs) / 2.0s)
4.2098mAs / 2.0s
2.1049mA

(This current draw was measured at 3.0v, so this calculation won’t be entirely accurate due to the voltage dropping over the time period of the test.  It should give us a ball-park answer though.)

It took 7 days for the beeper to be quiet enough that it was no longer serving it’s annoying purpose, so let’s see how many milliamp hours it consumed during this time.

7 days = 7*24 hours = 168 hours
 168 hours * 2.1049mA = 353mAh

This is significantly more than the 240mAh claimed in the datasheet, which is probably accounted for in the fact that this device is drawing current at a much lower average rate than was used to calculate the 240mAh, and the fact that I’m not taking into account the decreasing voltage and it’s effect on the current draw.

Now, I’d like to figure out how this relates to the current draw when it’s beeping every 5-8 minutes instead.  The average period in this case will be:

(5*60 + 8*60) / 2 = 390s

390s instead of 2.  Now, we can’t just take 390s/2s = 195 and multiply the result by 195.  That wouldn’t take into account the fact that the ratio of time it’s beeping is changing.  It’s still just 0.6s, but 0.6s every 390 seconds instead of every 2 seconds.

Let’s do the math again, with 390s:

((390s-0.6s)*0.007mA + 0.6s*7mA) / 390s
(389.4s*0.007mA + 0.6s*7mA) / 390s
(2.7258mAs + 4.2mAs) / 390s)
6.9258mAs / 390s
0.01775mA

So when this is running with it’s normal settings, it’s average current draw will be around 0.01775mA, or 17.75 microamps!  How does that compare to the test scenario?

2.1049mA / 0.01775mA = 118

The average current draw of test is 118 times that of normal operation.
So, it lasted 7 days before it got too quiet in the test, so if we multiply that by 118, we get 826 days!  That’s over two years.

Now, since we didn’t account for changes in voltage, or the fact that some cells may have been on the shelf for a while, and won’t start at quite the same capacity, in addition to normal losses of capacity over the 826 days (just like sitting on the shelf), we can’t realistically expect them to last that long.  But, I think it’s realistic to say they should last for many months before they get noticeable quieter.

If anyone has information to share about how to account for the drop in voltage over the time of the test, I would be very interested to hear from you.