Got the Screen Replicator to Work

I have been trying to figure out what I am doing wrong with the screen replication on the RPi. Then it hit me, I wasn't using the right XWindows display. I was relying on tightvncserver to deliver a desktop on the iPad that was the current command login. That will not work because tightvncserver will always give back a different display/desktop as though you were a different person logging in. What I needed was to specify display :0. Here is the resulting duplicated display on my iPad 2.




Update:  it turns out there is really nothing magical here.  I used x11vnc to be the vnc server primarily because I can do some XWindows kinds of things with it.  The launch was by "x11vnc -display :0" and that set up the vnc server to display the current logged in screen.  Note that the other part of the issue was to set up a wi-fi access point that the iPad could access.  The iPad 2 is running iSSH which is a fairly decent SSH/VNC/RDP client on iOS devices.  Now that the screen replicator is out of the way, I can concentrate on the rest of the 1-port router that I was trying to build.  Additional information on using VNC servers can be found at http://elinux.org/RPi_VNC_Server.

Old Notes:
Over the weekend I worked on the 1-Port Router idea.  I started with some knowns and quickly became bogged down in some details.  I started with implementing the instructions at http://learn.adafruit.com/setting-up-a-raspberry-pi-as-a-wifi-access-point.  That didn't work so well until I realized that I had unplugged the connection to the incoming house router on Saturday because there was an area Verizon service outage.  Once I got that situated the install went without a hitch (I also did not specify the wireless driver in the hostapd instructions).  I was able to use the RPi as a Wi-Fi access port with the connection to the outside via the native ethernet port.  Next up, I wanted to get a separate wireless card to connect to my home network.  My reasoning was to have the ability to re-use the 1-Port Router on the outside, notably at work.  At work is a proxy that we allow guest access to; perfect for making modifications to the RPi during lunch break.  I use this with my iOS devices and it keeps me out of the corporate network and allows me to go pretty much anywhere.  I completely unable to get the new wireless usb adapter to work.  It almost seemed that the driver was not being recognized, however, when I plugged the new wireless usb adapter into the RPi first, it assumed the role of the Wi-Fi access port.  So now I am confused.  How do I get a multi-functioning router to work the way that I want it to?

I also played around with setting up my iPad 2 to be used as a monitor for the RPi.  I have a Logitech wireless keyboard w/usb dongle that I can use for the keyboard and trackpad, but I wanted a separate monitor that would be portable.  I have my iPad 2 with me at work and I thought that would be a perfect choice.  I have an iSSH app that gives me both VNC and RDP access and I was thinking that I could link the iPad2 into the RPi Wi-Fi access port and use a VNC connection from the basis ip address.  However, when the Wi-Fi access port was actually running, and I had installed TightVNCServer I was unable to connect to the RPi at the same screen that was being controlled by the Logitech keyboard.  So back to the drawing board.

Implementing a 1-Port Router

Now that I have a somewhat better handle on the Tor Proxy, I am back to thinking about a 1-Port Router.  One of my next experiments will be to plug the RPi Tor Proxy into a tagged vlan port.  I am hoping that I can use Shorewall and some vlan libraries to make a one port router.  It would appear that this will be safe since there is no physical access to the cable that goes from the managed switch to the RPi ethernet port.  My idea is to use Shorewall as the main routing mechanism to isolate separate vlans from each other (except in certain cases), but still provide dhcp services to a couple of the vlans.  So now I am thinking the following:

1.  The RPi will be connected to a managed switch with a single ethernet connection.  The ethernet connection will be limited to tagged packets on several vlans only.  The vlans that will be considered involve a vlan for Media, for Experimentation, for Personal services, and for Extra-network connection (i.e., to the ActionTec router).  Non-tagged traffic on the switch port will not be allowed.
2. The RPi will provide dhcp services to the Media vlan.
3. The Tor Proxy will provide a firewall to the Extra-network connection; all Tor related traffic will be on this vlan.  Access to the Tor Proxy lan will be via a WPA2 wireless (per the Onion Pi setup).
4. The Tor Proxy lan should be isolated from the RPi itself.
5. The Personal services vlan will be allowed to connect to the Tor Proxy and then to the Extra-network vlan.  The general Tor Proxy lan will not be allowed to access the Personal services vlan.
6. After analysis of the connection to the managed switch, I have come to the conclusion that the only possible problem with the hardware setup is that the wireless connection (for the Tor Proxy) might be able to be compromised.  Perhaps I should think of implementing a RADIUS server of some sort.  I could host it on the RPi but that might be a security issue.
7. I would also like to add a separate wireless access port setup with a separate wireless dongle and ethernet-usb connector.  I would make that one subscribe to one specific vlan.
8. Implement an LCD panel control for all of this?

I am still coming up with ideas at this point but this looks to be a useful device within my network at home.

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.

Just Got In A Midi Shield for the Arduino

I ordered a Sparkfun Midi Shield the other day along with some appliance lights that needed modification.  The midi shield came in last night.  I was a little disappointed when I saw the baggie and noticed that it did not contain any Arduino headers.  Fortunately, I have a Micro Center close by that carries the headers so it shouldn't be any issue with getting some to get the midi shield built.
What do I have in mind for this device?  I am planning on making a midi swiss army knife to use with my existing midi equipment.  Among the things that it should be able to do is swap channels, integrate well with the midi foot controller, etc.  I haven't really thought of all the applications just yet.  Some possibilities include the following:

1. Midi Thru


2. Midi Channel Translation


3. Arpeggiator


4. Midi Channel Merge

The Midi Shield is next to a Sparkfun Power Supply which obtains power from an old ATX computer power supply; neat concept.

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.