Tag Archive for 'led'

Enabling the NRF24L01+ for ACRIS

Okay, it’s finally time for making a wireless version of ACRIS. I’m damn tired of stringing up CAT-5 cable everywhere.

So, I’m exploring possible wireless communications systems. My first choice is those based on the Nordic NRF24L01+ chip, which operates in the 2.4GHz spectrum. You can get a variety of turn-key modules from DealExtreme with PCB antennas or more powerful on-board amplifiers and external antennas for practically nothing.

I started by buying three PCB-antenna modules so that I could characterize them. Three weeks later, they finally showed up.

Designing a Reasonable Firmware Architecture

The next step was to write a library for ACRIS. Ultimately, the goal is to convert the whole system, bootloader and all, to be fully wireless. Of course, instead of just starting by writing some tests, I decided to redo the entire ACRIS firmware architecture. Originally, I was going to work on a separate branch, but then when I saw that Github doesn’t count non-master commits on your dashboard status, I got angry and merged it all into master. I also wrote a shitload of READMEs to describe what everything does (or rather, should do).

I finally learned how to make Makefiles from scratch instead of just going off of random other ones I found on the internet. I swear I’m going to start using make for everything ever now. But anyways, I wrote a framework for building and programming all projects in the [cci]avr/prj[/cci] directory. The new firmware architecture is described in this README.

Writing the NRF24L01+ Driver

After porting all the existing code to the new architecture, it was time to start writing a driver for the NRF24L01+. The NRF communicates with an MCU over SPI. Unfortunately, the ATmega168 only has one SPI module and I wanted to dedicate it only to the TLC5940 LED drivers since they use a non-standard way of latching the data (it’s possible to work around this and support everything on the one SPI bus but this would generate a lot of extra traffic on a bus I’m trying to keep quiet).

So, I decided to use the USART in SPI mode, as Atmel documents in their datasheet. In this mode, a third pin is used for the clock ([cci]XCK[/cci]) and [cci]TXD[/cci] and [cci]RXD[/cci] are used for [cci]MOSI[/cci] and [cci]MISO[/cci]. I was lucky enough to leave the [cci]XCK[/cci] pin unused in the LED controllers, so I can actually rework all of my existing LED controllers really easily.

At the same time, though, I need to make a device that translates commands from UART or USB to packets for the NRF. This means that I must use the USART for regular serial communication and SPI to communicate with the NRF.

So, I wrote a communication layer: a common set of commands for sending and receiving bytes and streams of data. The underlying driver can be selected as either SPI or USART depending on which file is compiled, but the API is the same.

On top of this layer, I wrote the actual driver for the NRF24L01+. Unfortunately, the code so far is pretty rigid. It doesn’t easily handle cases like being able to reconfigure the chip quickly. But it does expose functions for reading and writing registers, flushing buffers, transmitting a packet, set up reception, etc. I still have plenty of work to do on it, such as enabling double-buffering for received payloads, setting up ACK payloads (e.g. for communicating LED controller status information), etc. Maybe I’ll add support for their MultiCeiver architecture (automatic handling of multiple transmitters). Depending on how I intend to use it in the future, I may also modify the SPI architecture to be interrupt/event-based.

After a bunch of debugging, I finally got some test firmware working. Building the project [cci]test-nrf[/cci] with [cci]MODE=tx[/cci] will set the project up to be a transmitter and [cci]MODE=rx[/cci] will set it up as a receiver. When one of each is programmed onto two different boards, they’ll talk to each other and the receiver will spit data out via serial. The result?

The range of the modules is pretty decent. I can reach all the way to the other side of my apartment without any issues. But, the caveat is that the two must be in line-of-sight. Pretty much any wall will completely stop all communication. Now, this is using the 1Mbps data rate with Enhanced ShockBurst enabled. If I disable Enhanced ShockBurst and switch to 250Kbps, I might get better results.

OTOH, I also just bought a few of these modules. They use an external antenna and have onboard amplifiers which boost the gain by a whopping 30dB. So, I’m hoping that I’ll only need one of these and then can use the PCB-antenna modules in all of the lighting controllers for reception. The only possible problem with this is that the receivers may not be able to send back ACKs that the transmitter will hear. In this case, I’ll have to disable Enhanced ShockBurst and come up with some kind of isosynchronous transfer mode where the transmitter won’t care about ACKs. But then I won’t be able to enable auto-retransmission and reprogram the controllers wirelessly, which would really suck.

I’m waiting for some 3.3V LDO regulators to come in from Digikey so that I can rework the LED controllers. Right now, I’m using LM317s with a bunch of trimming resistors to make the supply voltage around 3V3.

ACRISifying an IKEA FADO Light

So we bought this FADO accent light from IKEA and frankly, it’s kind of… well… boring. I thought that maybe I could breathe new life into it by converting it into an ACRIS lighting instrument. For bonus points, I tried to do it in the least destructive way possible. Here’s what I did:

The first step was to rip out the old guts. I used a screwdriver to carefully open the tabs connecting the lightbulb assembly to the base.

Then I pulled out the wires that run through the base and into the lightbulb assembly.

Next, I used a dremel to grind down the side supports on the tabs to make a little shelf. I’m still letting this count as non-destructive because you can still assemble the original parts easily. Okay the assembly is ready to go.

Now came the fun part. Since it’s impossible to differentiate multiple LEDs in the light (I tried — looks like crap), it’s easiest to just solder all of the LED terminals together, and bring 4 wires out through the base.

It started with this:

And ended up like this (ugly, I know):

Then, I modified the controller a bit by wiring 3 pairs of channels together to handle the current from 3 LEDs. I screwed the board into the light base and carefully put the globe on.

The result isn’t half bad:

For hipster points, I took an instavine.

Unfortunately, there’s a few problems. First, I don’t have useful tools so I had to tape the damn thing together. Not good. Second, there’s no heatsink on the LEDs, so I’m not running them at full power. Third, I need to extend the feet on the base out a bit more so that the board is protected. Fourth, if I wanted to take it apart, I’d have to unplug all the LEDs and unscrew the board before I can reach the weird little springloaded thing that keeps the light bulb on the base.

But overall, it actually works quite nicely. I think when I bought them here in the bay area, they were like $15. I might buy some more!

First steps toward a PCB business card

I have been toying around with some ideas for PCB business cards. I wanted something cheap, clever, and not gaudy. I also wanted to make something that I could potentially etch myself to save on cost. What I’ve come up with so far is bcard. In addition to having my name, contact information, and QR code linking to my website, I designed a simple capacitive touch sensor scheme whereby pressing your finger on the button will make the LEDs located at the corners of the card light up. These are blue LEDs, so I’m actually thinking of inverting them so that they point into the PCB. As a result, the PCB should actually fluoresce. But that might not work… IDK.

Here’s my initial design. It uses an ATTiny10, a small transistor, 4 LEDs, a cap, and a resistor. The cap is probably unnecessary. There’s also two pads which I’ll probably make generate signals or something fun. The battery holder isn’t showing up correctly, but basically it’s just two pieces of metal that will sandwich the battery, which fits fully flush in the board.

I’m going to try to etch it soon and see how it turns out. It might be a total disaster, but I’m hoping otherwise. 🙂

Glowscape – An Experiment with Glowstick Dye

It’s been like forever since I’ve blogged. Sadness. Here’s something cool though. 🙂

A while back, I bought an absurd amount of glowsticks for a few bucks on Woot.com. I was wondering what I could do with some of them.

One idea I had was to make some kind of art thing or whatever. After a little preliminary investigation, I discovered that the glass vials in the glowsticks were full of the fluorescent dye that can also be activated by ultraviolet light. So I decided to test it out.

Basically, I just taped a UV LED to the bottom of the glass vial that normally goes in the glowstick. It actually looks not bad. I set up a quick demo with some UV LEDs. Hmm… what could I do?

Maybe a VU meter for sound? Yeah, that might work. 🙂

So, I grabbed 16 red, orange, yellow, and green glowsticks and headed over to MITERS to get to work.

The first step was to sand down the LEDs so they were flat. First they got the bandsaw treatment, followed by some more gentle loving with fine-grained sandpaper.

Hell yeah. All right, time to cut the glowsticks open and extract the glass vials.

So the other stuff left in the plastic part of the glowsticks is high concentration hydrogen peroxide. I decided to save it in a bottle. The concentration is so high that it’s actually very sludgy.

Next step was to sand down the end of the glass vials to make them as flat as possible. Then, I used duct tape to hold them against the UV LEDs.

All right. So then, I ended up letting the project sit for several weeks because I got super busy at the start of the semester. I also had to layout a PCB for the design I wanted. Essentially, my plan was to make something compatible with ACRIS but also provide a standalone mode so that it can independently analyze music.

But, I didn’t want to pay people to produce a board. I wanted to do my own etching. Previously, doing this was extremely difficult because MITERS didn’t have the right tools to do it.

To refresh your mind, etching goes like this. First, print out the PCB layout onto photo paper with a laser printer. Then, use a heat source to transfer that laser printer toner onto sanded copper-clad board. Next, throw that board in PCB etchant and wait for the copper you don’t want to disappear.

But it’s never that simple. The real problem is the transfer. My awesome girlfriend Jordan used a clothes iron to perform the transfer. This method is incredibly unreliable. It’s really hard to get right and every time I’ve done it, I’ve always lost huge portions of the transfer. Jordan made several boards and the later ones she built looked absolutely spectacular — she figured out the exact amount of ironing time and pressure. I’ve tried to do this too, but I’ve never been able to get it right.

But I got to bypass all that because MITERS recently bought a laminator. Laminators provide an even amount of heat across the board with relatively little pressure, so they transfer the toner perfectly every time. Check this out:

The other awesome thing is that MITERS found some new paper that’s really perfect. Usually, it is recommended that you use glossy photo paper. But, a lot of photo paper is very plastic-y. So, when you iron it, the plastic actually forms a boundary so that when you try to wash off the paper after the transfer, it never gets soaked. This new paper isn’t photo paper — it’s just regular glossy printer paper. And it works perfectly because it washes off really easily.

Another thing is that I made the traces really thick because I didn’t want to take any chances. You can’t really do very complicated boards this way. In the future, I’m going to

Next step was to throw it in the etchant. MITERS reuses etchant a lot, so in combination with an agitator, the etching time was about 30 minutes total. It’s important to constantly check it because you don’t want to etch longer than you have to — otherwise you may etch underneath the toner.


Okay. Time for drilling. This one is really hard. It’s very difficult to drill small holes through fiberglass — you can easily blow through a pack of bits if you don’t know what you’re doing. MITERS has this cute little drillpress that I forgot to take a picture of. But it does a great job of drilling stably so that the bit doesn’t break.

Okay, time for board assembly.

Ugly jumpers are ugly. 🙁

My first idea was to align the tops of all the tops of the glowstick vials.

Then I didn’t like the lead spacing at the bottom, so I put it back.

On the first power-up, one of the UV LEDs blew out. Not sure why — I think the quality control on these LEDs is kind of bad.

IDK, it’s not as bright as I would have liked, but I’m trying to figure out what I can do about that. Here’s a video of it just doing a simple chaser effect:

Schematics and board layouts are available on the project page.

ACRIS LED Bootloader Ready!

The last major hurdle for the LED controller is finally done. I’ve finished designing a bootloader that allows you to program the device over the RS-485 network, thereby eliminating the difficulties I had originally experienced with in-circuit JTAG programming. I’ve also finished a Python library and application that makes working with the bootloader quite easy.

I just need to do one final verification of the LED controller boards and then I’ll order some. After that, it’s just a matter of assembly and writing some programs to control the colors of the system.

Seven Segment LED Control FPGA Module

I was bored last night, so I decided to write up a small module for my Nexys2 that would allow me to easily control the 4-digit 7-segment LED display on the board. Quite simply, this module allows you to enter a single 16-bit number and the corresponding hex value will be written out on the display. You can also set any number of the four decimal points. There is another input mode as well: if you want to update just a single digit of of the array, you can give that a new value without disturbing the others. Here’s the obligatory photo:

You can download the VHDL module here. I’ve also written a small testing environment that takes the output of some UART like Digilent’s RS232 module and uses two bytes of data to set the corresponding numbers on the display.

The module is really simple to use. First, you may need to set the CLKDIVAMT value inside the module depending on your oscillator (I used a 50MHz oscillator); the internal clock divider simply just sets the refresh rate of the display (since we update one digit at a time, we must update them fast enough so that the user doesn’t see any flickering).

Next, when you instantiate the component, you’ll need to feed in your clock, a reset signal (I haven’t tested this, but it should set the numbers all to 0), and specify the output anodes and cathodes of the LEDs on your board (for a seven segment LED, I wired ctout(7) to the decimal point value). Next, you need to take care of inputting the data.

The easiest way to input data is to set useseg to ‘0’ and then feed in a 16-bit number into val and set wen (write enable) to ‘1’. This will push in new data for the display to show.

To enter decimal points, set or clear the corresponding values in dp and then use the wendp enable mask to perform an action. For example if you set dp <= "1101" and wendp <= "1110", the module will turn the decimal points on for the two most significant digits and turn the decimal point off for the third most significant digit, but it won't change the least significant because wendp(0) is 0. Finally, there is one other way to control the digits, using the seg{3,2,1,0} signals. With this mode, you can update a single segment without affecting the others. To do this, set useseg <= '1', seg{3,2,1,0} to whatever 4 bit values you'd like (again, you don't have to set all of them), and set wenseg to the mask of values that you want to change (it works like wendp -- if you set wenseg <= "1001", the most significant digit and least significant digit will be updated).

Evaluating LEDs for ACRIS

I got sidetracked (what else is new) from my audio visualization project and things have been progressing somewhat slowly.  First of all, my oscilloscope has randomly decided to stop displaying channel 2, so I need to fix that at some point so that I can use my spectrum analyzer again.

Anyways, I recently received four RGB LEDs from DealExtreme.  DX sells two types, so I bought two of each to determine which one to buy for my lighting project.  The first one I saw is on a star board and is cheaper than the second, which is enclosed in its own casing.

First, a few pictures:

These pictures were taken while the LEDs were being driven with very little current.  The star emitter is supposedly rated at 350mA for each channel and when each color is driven at this current, the LED is extremely bright.  I initially anticipated needing around 20-25 LEDs for each wall lamp, but I can see that 5-10 will definitely suffice.

I think I know why the star emitter is so cheap.  It’s labeled incorrectly.  The emitter, like most others, is common anode, meaning that the + terminal is common to all three colors.  The markings on the board are indeed wrong.  The enclosed emitter is also common anode.

Here’s a graph of some preliminary tests of driving the diodes at different voltages.  I pushed the enclosed one a lot harder, so I will need to set up a more rigorous test for complete characterization of the diode.  Also, I wasn’t able to heatsink the encased emitter, but stuck the star emitter on a big block of aluminum with some thermal compound.

As is fairly easy to see, the voltage curves look very similar between the two emitter models, except for the green channel.  However, it is also important to note that at 350mA, the first LED did not get anywhere near its rated operating voltage.  I haven’t pushed it far enough to see just how much current is necessary for it to be at is operating voltage, but the diode is certainly bright enough at 350mA.  I don’t want to overly degrade the diode by pushing it too far, or my wall lights will keep breaking.

I’ll probably go with the star emitter because it’s easier to attach a bunch of them to a heatsink block.  I’ll definitely need some kind of diffuser for the lamp, though.

The enclosed diodes are great for custom LED projects where you only need one or two of them; I wouldn’t recommend it for creating a compact array, though.  I might use them in my computer case or something; I could make them change color depending on processor load.