From Mouser

I always wanted to work with Frostbyte on his POV towers, but I didn't really have the electronics skills necessary while I was in Boston, and once I moved to New Mexico it was logistically impossible. Now I guess I'll never have the chance, so I've decided to build up something functionally similar from scratch.

Table of contents

1 Functional Overview 2 Design Criteria 3 Component Selection 3.1 pixels 3.2 PWM drivers 3.3 Microcontroller 3.4 Power Supply 4 Layout 4.1 The Data Return Signal 5 Prototyping 6 Questions to be answered

Functional Overview

A microprocessor controls the state of PWM drivers which in turn control the light output from a linear array of LEDs. There will be two operating modes: POV and linear-image. In POV mode, the array of LEDs represents a single column of an image. The microcontroller cycles through columns of a bitmap image in such a way that if the LED array pans across your field of vision, it draws out the bitmap on your retina and you see the complete image. In linear-image mode, the LED array is meant to be observed without moving and the single-column image is the content itself. Presumably, the linear image would change in time in a way that was pretty. This could either be a sort of "one-dimensional screen saver" or something reactive, like a frequency analyzer connected to an audio source.

Design Criteria

• full RGB pixels
• 8 bit PWM brightness control for each LED (or each component of an RGB LED)
• arbitrarily fast refresh rates for experimentation with POV effectiveness
• realtime computer control of mode, image content, etc.
• scalable array length

Component Selection

pixels

There are numerous monochrome LED POV devices out there, so I decided early on that I wanted full color pixels. I had to choose between small (and dim) surface mount RGB LEDs or arrays of large (and bright) individual-color LEDs to form RGB pixels. At least initially, I am more interested in high-resolution than in brightness so I am going with SMT RGB LEDs. After purchasing some samples of various SMT LEDs from LEDtronics.com, I have decided to use the SML5050RGB1K-TR product. It is 5mm x 5mm in size, has independent cathode and anode leads for each color element, is reasonably bright, and has good color fidelity across the spectrum. The green element is much brighter than the red and blue elements, but this can be accounted for by systematically reducing the green brightness when calculating the PWM duty cycle. Each of the color elements is designed to handle 20mA of current continuously. The green and blue elements have a forward voltage of 3.8V while the red element has a forward voltage of 2.8V. I will drive the red element from a 3.3V supply to improve its efficiency, while the blue and green elements will be driven from a 5V supply.

PWM drivers

The MAX6966 (http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4539/ln/) 10-port constant-current LED drivers and I/O expanders with PWM intensity control are basically perfect for this application. They are daisy-chainable to arbitrary depths, take SPI input at obscenely fast speeds (20MHz clock, 17.3MHz if daisy-chaining), have built-in 8bit PWM (pseudo 9bit brightness using the "half-current" bit), and because they are constant-current and can sink 50mA per channel, I don't need external resistors for the LEDs. Also, the common-cathod arrangement means that I can supply different power supplies to the different colors of LEDs to suit their forward-voltage requirements to maximize efficiency.

The daisy-chaining and fast SPI bus mean that I can chain together drivers for the entire LED array and control them all with a common /CS line, basically sending an unique command word to each of the 6966s simultaneously. During operation, I would have to send one such command cycle for each channel since a single command word can only update the status of a single output channel. This means 10 command cycles would equal a complete update of the LED array status. Each command word is 16 bits, so the number of bits needed to be sent out over the SPI bus to update the entire array would be 160*n where n is the number of 6966s in the chain. With a 16MHz SCLK, this means 10*n microseconds (or 3.3*num_rgb_pixels microseconds) for a full column update. That's plenty fast for experimenting with very long arrays and quick refresh rates. Ada indicates on her MiniPOV2 (http://ladyada.net/make/minipov2/index.html) site that 400Hz makes a good refresh rate. To maintain a column update of 400Hz, I would limited to about 800 pixels, which is probably more than I can afford to build anyway.

Microcontroller

The processor needs to have hardware SPI support and be capable of driving the SPI bus at 17.3MHz. It will likely be doing a lot of background work preparing column updates and communicating with the computer, so a fast clock rate is preferrable. Hardware RS232 support is also required, until/unless a different method of communicating with the computer is chosen (Ethernet??).

The initial prototype will employ a Silicon Labs C8051F007 microcontroller because I happen to have one laying around and I have access to all of their development tools. The 'F007 has hardware SPI, UART, and a maximum system clock of 25MHz. It runs off of a 3.3V supply and draws very little power. The maximum SPI SCLK frequency is sysclk/2 or 12.5MHz, so it will not quite be able to push data to the 6966 drivers as fast as they can accept it, but 72% of maximum should be sufficient for now. I suspect that until the LED array gets very long and the number of drivers in the chain becomes large, the bandwidth of the SPI bus will not come into play.

Power Supply

Will need a fair amount of current at 5V and 3.3V for the LED power rails. Depends on how long the array is, but better make it beefy. Each LED has a constant-current rating of 20mA and the 6966 can handle that much current on all 10 channels simultaneously, so we have to be able to supply 40mA of 5V and 20mA of 3.3V for each pixel. If we had 100 pixels, which isn't totally unreasonable, this would be 4 Amps of 5V and 2 Amps of 3.3V, so we're looking at more than just a 7805, etc.

Layout

Modular design with array segments and associated controllers on short boards that can be chained end-to-end to arbitrary length. The space between adjacent pixels should be constant, even over the joint between two modules. Connection of modules should be as simple as possible, note that the power and ground connections need to be able to carry significant current. Connections to each board:

• Ground
• 3.3V
• 5V
• Data in
• Data out
• Data return (brings the data out signal from the last module back to the microcontroller for read operations)
• Chip enable
• SCLK

The SCLK, chip enable, and the three data lines are all low-power, so their inter-module connection can just be some right-angle pin header and sockets. However, the SCLK and data lines are high frequency so there needs to be some interleaved ground traces between them. A possible pinout would therefore be:

  CE       ---- CE
  Data ret ---- Data ret
  GND      ---- GND
  Data out ---- Data in
  GND      ---- GND
  SCLK     ---- SCLK

In addition to this low-power header, a three-connection high power bus needs to be run from module to module for the power supplies and ground. If the LED array gets long then there is a possibility of many amps of current flowing through each of these lines, which is why I am uncomfortable using the GND lines on the signal bus as ground return lines for the LEDs. I can't gang them together because this would have to happen on every module and that would make ground loops galore. I'm not sure what the best way to distribute the power lines is. It would be nice if it were aesthetic (i.e. not a fat power cable running from module to module), but if I'm going to run the power along traces on the module boards then those traces will need to be really fat (0.2"+) and I'm still not sure how to make the inter-module connection. Do they make high-current fat pin header?

The Data Return Signal

The reason I included a data return line in the signal bus was to let the microcontroller be able to do status reads from the 6966 drivers. Of course for this to work there will have to be an "end cap" on the farthest module from the microcontroller which jumpers its data out pin onto the data return pin. Under normal operation, there's not really a good reason to need to read data back from the drivers. However, it has tremendous utility for diagnostics. For starters, the 6966 has LED fault detection and I can have the microcontroller detect any bad LEDs at powerup. Also, I think I can probably use this to determine how many modules are in the chain automatically. When the 6966 starts up, all of the driver channels are set to high impedance (LED off). If I send a single command word to turn on a single channel, only clocking out 16 bits and thus only affecting the first driver chip, then I can keep sending out status read requests (one word at a time) until I see the enabled driver channel come back. The number of status read words I have to send out to get this to happen is equal to the number of driver chips in the chain. Neither the broken LED detector nor the automatic array length detecctor are critical functionality, but I might as well leave a signal return path on the layout in case I decide to implement them.

Prototyping

See POV/Prototype_1 for an in-depth technical discussion of the first prototype hardware.

A series of steps towards the creation of a working large-scale POV array:

1. Obtain samples of various RGB LEDs. (Ordered mid January, $40. Arrived 2006.01.23)
2. Obtain samples of MAX6966 drivers. (Ordered mid January, $0. Arrived 2006.01.26)
3. Test for brightness and color fidelity. (Completed 2006.01.23) SML5050RGB1K-TR (http://www.ledtronics.com/ds/sml13rgb/DSTR0126.pdf) was chosen because it had excellent brightness, reasonable color fidelity, and was the cheapest of the LEDtronics SMT offerings. It was also the largest, but at 5mm x 5mm this was hardly a concern. It also has the benefit of being the only 6-lead package (no common anode or cathode), allowing for a separate cathode supply for the red element.
4. Order large quantity of SML505RGB1K-TR LEDs. (Ordered 100 on 2006.01.25, $129. Arrived 2006.01.30)
5. Order large quantity of MAX6966 drivers. (Ordered 30 on 2006.01.25, $70. Arrived 2006.02.03)
6. Design 10-pixel prototype board. (Finished 2006.02.03) The initial prototype will include three 6966 drivers and 10 RGB LEDs. The remainder of the components will be scavanged from available spares. Major functional blocks include the C8051F007 CPU, a UART with level shifter, 5V and 3.3V power supplies, JTAG programming port, and the lighting system. Schematic and board layout with ExpressPCB's free tools. Goals of this prototype are to test the functionality of the 6966 drivers and generate some basic code for simple RGB POV.
7. Fabricate PCB for initial prototype. (Ordered 2006.02.03, $59. Arrived 2006.02.09) This was done by ExpressPCB, using their "Mini Board" (2.5" x 3.8") fixed-price option.
8. Order assorted components. (Ordered 2006.02.06, $20. Arrived 2006.02.09)
9. Populate initial prototype board. (Started 2006.02.10.)
10. Generate skeleton code framework for control of UART and SPI bus with the 'F007. (Started 2006.02.10.)
11. Demonstrate functionality of drivers and LEDs. (Started 2006.02.10. Finished 2006.02.11)
12. Create basic POV functionality. (Finished 2006.02.11)
13. Design modular prototype.
14. Design control/power board.

Questions to be answered

• Noise issues with a fast SPI bus and a lot of PWM? Can it be overcome with intelligent layout choices?
• Do we need overshoot dampening termination on the SPI lines?
• Do we need interleaved grounds on the SPI bus?
• Will tri-color LEDs do (i.e. Can they be made to act like a true RGB pixel with good response across the color spectrum)?
• What is imitation crabmeat, anyway?
• What are good POV timings?
  • Column hold
  • Inter-column delay, if any
  • Inter-frame delay
• What is a smart way to handle the bitmap image in memory to expedite sending data to the drivers?
• What is the best way to control the microcontroller from the computer (protocol, UI, etc.)?
• Does anyone want to help with this?
• Are any of Frostbyte's designs in the public domain?