LED Cube Changes for Test

I have decided to scale down the LED Cube to a 5x5x5 in order to test out the timing and construction.  Unlike a lot of LED Cubes that can be found on the internet, I have not had a lot of free time to spend on this endeavor.  Scaling down like this will enable me to at least build a cube with the parts that I have on hand.  Then, as I have some spare time available to me I should be able to test it out fully.  Besides, a 5x5x5 cube only involves soldering 125 LEDs together not the 512 LEDs associated with an 8x8x8 cube.  Aesthetically, it would be more pleasing to have the 8x8x8 or even a 10x10x10 cube but I really don't have the time to devote to it.  This is just for fun anyway.  So a slight change to the connection diagram:




This reduces the MCP23017 count down to 6 or 7, well below the 8 maximum addresses for a single I2C bus.  I will still attempt to do this through one or two Arduinos for control along separate I2C busses.  This structure also means that I will be controlling the Arduinos on one I2C bus from the Raspberry Pi.  So three small computers in the mix.

LED Cube Project Revamp

Ok, just ordered 90 more RGB LEDs to do some more testing of the concepts.  This time I am going to interface the RPi through a couple of Arduino UNOs.  The diagram is as pictured:





This shows a bus structure in which the Raspberry Pi interfaces across the bus to the two Arduino UNOs and in turn, the Arduinos interface to the MCP23017s.  I am hoping that this structure will resolve some of the timing issues that I was experiencing last year.

Thinking to get back into the LED Cube Project

Now that I have more time to myself, I was thinking of getting back into the LED Cube Project.  I was also thinking of adding a reflective LED projector to the experiment in order to have something that I can use later during the Halloween and Christmas seasons.  The controls are about the same except that the LED projector would have moving mirrors to reflect an LED strip onto a wall (for instance).  The reflection could also be done to a Conical shaped mirror for use on the lawn.

I have also purchased an additional breadboard to get some of the previous ideas prototyped up and working.  Remember, at last juncture I was unable to get enough control lines due to the chip that I was using running out of address space.

Reworking Some Ideas on the RGB LED Cube

I have not been working on the LED Cube for a while.  Now that I am back to thinking about it, I want to redefine the interfaces from the Raspberry Pi.  I was thinking that a good way of doing this would be to interface to the LED Cube through an Arduino.  I could re-purpose an Arduino to be an I2C device coming in with additional I2C busses going out.  The repetitive nature of flashing the LEDs is ideal for the Arduino.  I could have the RPi formulate the 3D nature of the data points at each phase and have the Arduino take care of displaying the 3D points in the LED Cube.  So the RPi would calculate what should be displayed, relay that to the Arduino, tell the Arduino to start displaying the new 3D point set, and while the Arduino switches to the new data set, the RPi would be busy calculating a different 3D point set.  The nature of our eyesight is that we need to have things change at roughly 1/24 of a second (frame rate) to visualize motion.  That should be easily attainable with the Arduino.  The RPi is better suited to gather other pieces of information.

Electronic Diagram for Portion of Slice 2x2

I decided to put up a portion of the slice electronic diagram to show the connections between the RPi, the MCP23017s, and the RGB LEDs.  This is a 2x2 RGB LED circuit, which in turn is one fourth the size of the 4x4 test slice that I have been using.  The main thing to note is that this is scalable.  At each level of the slice, the anodes of the LEDs are tied together, in each column, the Reds are tied together, etc for the LEDs.  There is one PNP transistor per level to allow current through and there are three NPN transistors per column to control Red / Green / Blue respectively.

What Problems Do I Now Know on the LED Cube

The test slice implementation revealed a number of issues that I had not really considered.  First of all, it is starting to appear that there are some timing issues that I will need to deal with if I decide to use Python as the programming language for the LED Cube.  Python, being an interpreted language, does make calls directly into libraries which speed up the execution.  However, it will show some issues with things like loops and execution times.  I find it weird that it doesn't have an array in the normal sense of the word as part of the language; but relies on a separate library to define such things.  There are a number of things that Python does that are kind of neat like threads and interrupt handling which might be able to get around some of the more formidable timing problems.

Secondly, there is a definite problem with addressing that needs to be addressed.  I need to access 16+ MCP23017 chips for an 8x8x8 LED Cube and each chip only provides for eight separate addresses.  Therefore, I will be forced to use another chip which will break the I2C bus into 4 or 8 separate buses.  This will add some overhead to the timing as well.  Update: the chip I have in mind is from Philips; the PCA9546 or PCA9548.

Thirdly, I have had to use a bi-level circuit between the RPi and the proto-board in order to get the I2C pulses to be recognized.  I want to run the proto-board on 5 volts, not 3.3 volts. There did not appear to be any way of getting the MCP23017s to be recognized by the RPi without the bi-level circuit.  That has to be worked into the final product.

My first blush tells me that I will need to access a four dimensional array in order to independently address all of the RGB LEDs and address each color independently.  I was thinking of a Row Major form addressing scheme:

Psuedo Code for LED Cube Addressing

Assumptions: the player will be fed the total LED address space while the next frame is being built

define NUMSTACKS # total number of stacks along a slice (x component) - for test, 4
define NUMLEVELS # total number of levels along a slice (y component) - for test, 4
define NUMSLICES # total number of slices in the cube (z component) - for test, 1

# the array will be NUMSTACKS x NUMLEVELS x NUMSLICES x 3 dimensions, the last being RGB color space
# this is a zero-based indice

# for tuple (a,b,c,d) where:
#   a is the stack number; 0 -> NUMSTACKS-1
#   b is the level number; 0 -> NUMLEVELS-1
#   c is the slice number; 0 -> NUMSLICES-1
#   d is R, G, or B; 0 -> 3-1

# position is d + 3*(c + NUMSLICES*(b + NUMLEVELS*a))

get_position(a,b,c,d) = d + 3*(c + NUMSLICES*(b + NUMLEVELS*a))

The next blush indicates to me that I will need to display a frame at a time.  Translation: it will be like a movie being generated, one frame at a time with a frame display player playing the last known setup while computing the next frame.  The k parameter might seem weird at first but it has to do with dicing the displayed time into 16 increments to provide a duty cycle of on and off time for the RGB components, sort of a 16 colors for Red, 16 for Green, etc.:

Psuedo Code for Frame Display

Assumptions: the frame display player will be fed the total LED address space while the next
frame is being built

for (i=0, i<NUMSLICES, i=i+1)
   for (j=0, j<NUMLEVELS, j=j+1)
      for (k=0, k<16, k=k+1)
         for (l=0, l<NUMSTACKS)

            # at this point we grab Red value for the LED and set the values accordingly
            index = get_position(l, j, i, 0)
            value = LED[index]
            # check to see if we have exceeded our allotment
            if (value <= k) then
               set red at position on
            else
               set red at position off
            endif

            # at this point we grab Green value for the LED and set the values accordingly
            index = get_position(l, j, i, 1)
            value = LED[index]
            # check to see if we have exceeded our allotment
            if (value <= k) then
               set green at position on
            else
               set green at position off
            endif

            # at this point we grab Blue value for the LED and set the values accordingly
            index = get_position(l, j, i, 2)
            value = LED[index]
            # check to see if we have exceeded our allotment
            if (value <= k) then
               set blue at position on
            else
               set blue at position off
            endif

         endfor
      endfor
   endfor
endfor

At least I have the first bit of the logic worked up.  Now I need to code it up and check out the timing - I really need to be in the KHz range for changing.