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.

Got the first Proto working through the RPi

After getting the hardware put together for the 4x4 test slice, I was able to cobble together a test program in Python. Not a real spectacular test but it does run through 7 colors and each level. The results are as shown in this video:

First test of 4x4 slice

Strangely enough, it looks like there will be some timing issues that I will have to deal with.  The python programming on the RPi does not seem to control the MCP23017s very fast.  I was able to get about a 1.6 msec response time w/o sleep between each change that was made before I started changing out everything.  This may be due to python being more of an interpreted language than a compiled one.  In any case, my next step will be to look into individual addressing of the LEDs and how I will accomplish what I need to do.  I gotta think in terms of a video or movie, frame by frame, to get animation.  More later.

Had some time to wire up the test slice

I was home today and had a chance to finish wiring up the 4x4 test slice so that I can check out the concepts. The board is below:



It seems a little strange to have it together this early. I didn't think I would be done until the end of the summer with all that has been happening.

Setting Up a Bluetooth Audio Server on the Raspberry Pi

I kind of got interested in Bluetooth yesterday and what I might be able to do with it and my iPhone. I thought that I might start with an audio server since there were a number of articles on how to set this up. This is a real quick and dirty setup. So my hardware consists of:

- Raspberry Pi
- Powersupply and powered hub
- IOGear GBU521 bluetooth USB adapter
- Sabrent USB-SBCV audio adapter

I merged instructions from three locations:
https://www.modmypi.com/blog/installing-the-raspberry-pi-nano-bluetooth-dongle
http://www.raspberrypi.org/phpBB3/view topic.php?f=35&t=26685
http://www.ioncannon.net/linux/1570/bluetooth-4-0-le-on-raspberry-pi-with-bluez-5-x/

Bluetooth setup steps

1. do the usual "sudo raspi-config" to ensure that the defaults are set up right on the RPi
2. sudo apt-get update
3. install the Bluetooth audio related packages with "sudo apt-get install bluetooth bluez-utils blueman pulseaudio pulseaudio-module-bluetooth alsa-base alsa-utils pavucontrol"
4. note, lots of things installed here including printer drivers (bluetooth printing interface)
5. edits according to the raspberrypi.org article
6. plug in IOGear GBU521 bluetooth usb adapter, reboot
7. run bluetooth manager from control panel, sync up iPhone and RPi
8. setup loopback according to the raspberrypi.org article
9. play a tune from the iPhone, works!

Now I need to set up the Sabrent USB-SBCV audio adapter for better sound quality. I am looking at http://www.geekytidbits.com/raspberry-pi-unattended-audio-recordings/ for some inspiration.

More Later.

Started wiring up a test slice from the LED Cube

Well I have started wiring up a test slice from the LED Cube.  I am doing this mostly to work out the kinks in the electronics and to make sure that what I think is the correct way of doing it, actually does work.  I think that I have a good handle on the problem but time will tell.  So far, I have discovered that I am using a large number of breadboard wires.  I started by trying a 4x4 vertical slice.  In doing this, I have the opportunity to observe the connections for R, G, B, and level and how they interact together.  Once I have the circuit wired up, I can concentrate on the interface to the RPi.  I have decided to drive this thing from the RPi rather than go through an Arduino this go around.  I am gaining more confidence in the RPi and its ability to compute and think through the problem.  My interface to the LED Cube is strictly through I2C so there should be no challenges from the 3.3v vs 5v interfaces that seem to plague these projects.  Adafruit has a nice discussion on interfacing the RPi to the MCP23017 16 I/O chip that I will be using.  I decided to do the interfacing by "slice" which means that I will have 8 "slices" in total for a 8x8x8 LED Cube.  It also means that I can get away with 8 levels, 8 Red, 8 Green, and 8 Blue control lines for each slice.  That will mean that each slice is independent of the other slices.  It also means that I can concentrate on a smaller version at first and build up from there, hence the fact that I am making a 4x4 slice to write my test software on.  If I need something bigger than 8x8x8, I can multiply the "slices" in each direction.  I just have to write the software knowing that. The breadboard slice is shown below.



Right now it looks like it's going to be two MCP23017s per "slice" or a total of 16.  Unfortunately, the addressing scheme on the MCP23017 allows for 8 addresses, so I will be having to bring in a chip such as a PCA9548 to allow for more than one I2C channel.  Right now, the concentration is on just the test slice, then I can concentrate on other matters.

Working on a Design for an LED Cube

I have started considering what it would take to build an LED Cube.  I originally thought of a 5x5x5, but now am considering a cube as big as 8x8x8.  This provides a little more resolution in each direction; which is not a bad thing for putting up characters instead of patterns.  What will I do with it?  I was thinking of an art object but technical in nature.  Besides, what I really want to do is exercise my creativity with electronics and software.  That being said the following come to mind:

1. It should be made from RGB leds so that the color can be manipulated on each individual led by itself
2. The circuitry controlling the leds should be self contained
3. Minimize the power required to drive the cube
4. Minimize the interface to the circuitry that controls the LEDs to cut down on setup of lines and the overhead involved
5. Possibly use an I2C interface to the circuitry to simplify control
6. Build the cube in such a way that the circuitry could be modified to be bigger if needed

Development Work on Blackboard System is Still Plodding Along

I can safely say that this Blackboard implementation is taking a long time to design.  The real reason is that I only have a short period of time during the day in which I can attack the problem.  My job and home life take up a lot of my time and there are precious few moments in which I can be by myself doing the things that I like.  That is why I just plod along with the design, touching it here and there throughout the day when I have a moment to myself.

To date, I am trying to come up with a scheme to get the Knowledge Sources created and working within the Blackboard Controller structure.  I decided on making the Blackboard Controller run a state chart system as the Control Plan.  The first Control Plan executed is a bootstrap which loads the top level control knowledge source.  My first implementation of the Top Level Control Knowledge Source (TLC_KS) is driven by a builder pattern.  Later on, I will modify this TLC_KS to be able to load it from a set of XML descriptions.  That TLC_KS is the main element which causes all of the other knowledge sources to be loaded, some with their own control plans, the blackboard elements, and the top level control plan which orchestrates everything.  The top level control plan represents the problem to be solved and is composed of lower level elements arranged in a hierarchy.  The nature of a blackboard system is that at any moment a decision could be made to change the plan that is being executed.  That change is controlled by knowledge sources that react to the current state of the information on the blackboard.

I am just having fun putting the design together, learning about this type of system, and working through the thought process.  So what do you do for fun?