I was recently pointed to something called LumiLor from Darkside Scientific, which seems to be offering some kind of flexible contoured electroluminescent paint, basically flexible EL-wire that can cling to any surface or be any shape. (See this youtube video for a demonstration.)
EL-wire is made up of phosphors stuck inside a small capacitor which glows in the presence of an altering electric field (Jerie Ellsworth gives a good explanation here, in a youtube video explaining how to create your own wire at home.)
It turns out my theory on how LuminLor works is probably correct, as this other video from Ellsworth shows. The "stack up" as she refers to it, is a five layer silkscreen process, but in the case of LuminLor I believe it is a spray or paint application.
 |
 |
| Image from astounde/Darkside Scientific |
- You start with a base coat of a conductive material which acts as one plate of a capacitor. It can be either transparent or opaque; they seem to use a transparent layer because it allows you to also see a non-luminescent paintjob under whatever they're painting.
- Next a transparent insulating layer is laid down, probably a clear varnish.
- On top of that goes the phosphor layer, probably one of the inks available from Dupont. They might also be using a hydrographic process to put patterns of phosphor onto objects.
- A transparent conductive layer is laid down either after or along with the phosphor layer, completing the capacitor.
- Finally another layer of transparent varnish is laid down to insulate the whole thing and prevent shorts and shocks to the end user.
During the process, flexible electrodes are attached to the conductive layers, which are later hooked up to an EL power supply. (~120V AC @ 60-200kHz or so.)
The current mystery is how to get ahold of the phosphor ink, Dupont seems to have a website mentioning it but does not actively sell it. They do have a nifty pdf document describing some of the process used. They have several different recommendations for the build sequence, with the phosphor layer either inside the capacitor or on top of it.
Ellsworth provided a link to some students selling small amounts of the ink, but they're currently out of stock.
I'm doing work with one of my professors on an automated antenna test platform. We imagine our setup will work as such:
- WiFi router with antenna will be mounted to a general purpose antenna rotator.
- Computer with wifi card will run labview program/etc, map signal strength while rotating antenna.
Unfortunately the antenna rotator we got our hands on has a design out of the 1940's, the rotor base with antenna attachment and the control box have identical motors inside them. Moving the dial on the control box causes both motors to run until a relay is tripped in the control box. The assumption is that identical models of motors will run at the same speed, so dial position on the control box will accurately reflect the positioning of the rotor base. This is of course not how it works in practice, the error between the two builds up quickly and the control box has a feature to resync them (by rotating full left, followed by full right, not a smart device, just mechanical relays).
It turns out that all antenna rotators work like this, in order to remain backwards compatible. Even the newer control box we got our hands on (a Channel Master 9537A Antenna Rotor with an IR remote) was still just an open-loop DC motor driver. It'll have to do.
My current plan is to replace the control box's IR interface with a serial one. The first step is to reverse-engineer the remote control's protocol. This of course started with a google search to see if anyone had already done it. Success! I think. Here's what I found courtesy of Daniel Tonks. They have some sort of fancy universal remote that learned the IR codes of the device and the settings were uploaded to the internet. Here's what I extracted using the software Philips provided:
| Cmd | Code |
|---|---|
| Pwr | 1CE3 |
| rotor+ | 10EF |
| rotor- | 11EE |
| 1 | 01FE |
| 2 | 02FD |
| 3 | 03FC |
| 4 | 04FB |
| 5 | 05FA |
| 6 | 06F9 |
| 7 | 07F8 |
| 8 | 08F7 |
| 9 | 09F6 |
| 0 | 00FF |
Each command was prefixed with an identical header: 900A 006D 0000 0001 AC53
Something about this just doesn't sit right with me; its partially that I don't know exactly what these numbers represent (I assume binary data being transmitted) and its also that I've never heard of any IR protocol that would use anywhere near 12 bytes of data per command. I'll have to attach the remote's IR LED to a logic probe and check this for sanity.
In the meantime I'll have to work on the interface circuitry, as it will be the same regardless of what the commands will look like. I'm planning on building a tiny board with a serial header and a microcontroller. I'll remove the IR receiver on the controller and replace it with a signal coming from my board. As long as I sent the right code at the right speed it should perfectly emulate an IR signal.
Continued from my last post, the serial interface for the antenna rotator is now up on github.
The RX line on the serial header passes through a simple inverting level-shifter using an NPN transistor and a handful of resistors. This line also has a TVS diode tied to ground to protect it from electrostatic discharge or whatever might befall it during use.
The heart of the interface is an Attiny13 microcontroller which handles receiving and transmitting commands. The microcontroller's tiny and cheap and doesn't actually have a hardware UART interface, but its possible to use the USI system (Atmel's name for SPI) for half-duplex UART communication. According to Atmel's appnote on the subject the USI system should first be inactive and a pin interrupt should be used to detect the start bit condition. The interrupt service routine should then enable the USI system and switch its clocksource from the normal slave-clk pin to an internal timer calibrated to run at the same speed as the as the serial data being sent from the computer. Once all 8 bits and the stop condition have been received the USI system switches back off.
From there its just a simple process of matching up the received ASCII character to a table of commands. One pin on the microcontroller is connected to the control box's IR RX line (the actual IR receiver must be removed to prevent shorting) and data is sent across to the microcontroller inside the control box.
It should be noted that IR transmissions are usually sent on a modulated carrier (frequently 28kHz) and the overall waveform looks like a square wave made up of smaller square waves. The IR receiver is tuned to this specific carrier frequency, which prevents natural infrared radiation from interfering with the control signals. The signal that emerges from the IR receiver is stripped of this carrier frequency and looks like a normal square wave containing the binary data being sent to the receiver (usually a few address bits and a few data bits). By bypassing the IR receiver, my microcontroller will be able to send data without having to generate and modulate a carrier frequency.
The actual code that I'll be flashing to the Attiny hasn't been fully written yet. Until I know exactly what data is being transmitted by the remote control it won't make sense to try designing the program. In my next instalment I'll be probing the IR transmissions coming from the remote and coding the firmware to send commands to the control box.
 |
 |
| Images from Adafruit. |
After seeing this youtube video of a project called Sound Puddle, I was interested in creating a similar lighting system.
Around the same time Hackerbot Labs purchased a bulk order of addressable RGB LED strip, which seems to be the same model as this one carried by Adafruit. These strips use something like a LPD8806 chip to drive PWM to two LEDs at a time. The strip is marked with white lines every couple inches, where it can be cut to size using a pair of scissors.
Controlling these strips is kind of quirky. LPD8806 chips are actually FILO memory devices, each LED has an associated 3 bytes of memory but the MSB is reserved for chip reset, each channel has 7-bit PWM and data is latched asynchronously. You can get an idea of what's going on if you read the comments at the top of the arduino library file. Due to the chip's FILO nature, all the data to be sent onto the string must be held in memory and can't be generated on the fly and pushed down the line.
The board I designed (available on github) has an Atmega168 with a small microphone and a breakout to the SPI lines. It comes to just under 1.5x4cm which is the same width as the led strip. I'm planning on eventually wrapping the entire thing in heatshrink (the LED strip itself is waterproofed in plastic) and installing it in my shower. Alternatively, the board could be wired up to multiple strips and used in the same way as in the Sound Puddle demo. I'll post some pictures and video of it working once I program it.
A few changes had to be made to my board since I last posted, I had forgotten an important capacitor on the reset line. TTL serial programming on AVR chips requires a capacitor between the DTR line and the reset pin on the microcontroller in order to properly form a reset pulse during programming.
I also discovered that I lined up my SPI header backwards; all the pins are in the right order, but the PCB currently has to be turned backwards to fit it in-line with the LED strip. All these changes have been made and commited to the git repository.
Also just as an afterthought I connected the unused CTS line to an I/O pin. In the future someone may want to interface this board with another project, and this way the FTDI header can be used as 3 I/O lines, two of which are connected to the UART system.
|
||||||
 |
Programming of the bootloader was done with a USBtinyISP by inserting the programming pins into the SPI header and the reset line on the FTDI header. The MISO line was connected to the exposed pogo-pin pad on the board and held there during programming by hand. The fuses I selected can be read from the table on the right. Once the bootloader hand been flashed the FTDI header could be used to program the board in the standard arduino environment (the board was flashed and programmed as a Diecimila/Duemilanove w/ 168).
The program I uploaded as a test was a simple rainbow pattern taken from adafruit's demo code. Due to my omission of the DTR capacitor I had to add one between the FTDI header and the actual FTDI cable I was using. New versions of the board will have this included.
Below is a video of the system working with the test program. Partway through I bump the ground line by accident and it briefly disconnects. The LED strip dims but does not go out during this period. My explanation for this is that current is being returned through the data and clock lines and smoothed by the capacitors built into the strip. Its nice to know that the microcontroller can actually sink enough current to keep the strip running without destroying itself, but I certainly wouldn't suggest trying to operate it this way.