Major LED Cube update

When I created my 8x8x8 LED cube about 8 years ago, I programmed some fairly basic "patterns" into it. I'm only a novice programmer and I was happy with the result but I always imagined I would go back at some point and spend some more time programming some really great patterns.

Then I had some kids and they actually love the cube, and more and more I've been itching to get back and spruce it up with some fancy patterns.

Then around my birthday a couple of months ago I learned a new Raspberry Pi was released and it occurred to me that this would be an awesome platform for a "cube pattern generator" and so I started doing some research and hacking. I investigated replacing the PIC32 all together with an RPi and it's maybe possible but I decided that it was best to leave the PIC32 driving the TLC led drivers, even if the Rpi could do it "as good", there's no way it was going to do it "better". So the alternative is to leave the PIC32 as the drawing device and just feed the "patterns" to it from the RPi.

Before tackling the task of interfacing the two devices, which I knew wasn't going to be a picnic; I decided to test out some things and blow some rust off the old programming skills by building an LED Cube simulator. So I got a raspberry pi pattern generator talking to a LED cube simulator on my PC, to test out that everything worked how I expected, and I thought it would be cool to make one since I did just look for something open source first but couldn't find anything. Now anyone can use the LED cube simulator to make patterns or just "learn" without having to have built a LED cube first. I am hosting it and the pattern generator on github https://github.com/vespine/LED_Cube_Simulator

Fast forward about 4 weeks and I now have the RPi feeding patterns to my actual LED cube and the led cube simulator at the same time! and it's awesome, to see the hardware and software, both of which I created, running in unison is quite cool.

So, I haven't actually got to the part where I create the cool patterns, that will be the next bit after I take a little bit of a break from staring at configuration registers and bit translations!

Here's some media. I will put up some posts detailing some of the technical aspects in the future.

LED Cube at the Melbourne Mini Maker Faire! 14th Jan 2012.

My LED Cube will be an exhibit at the first Melbourne Mini Maker Faire on 14th Jan 2012!

If you want to come along you do have to book a free ticket because space is limited. If you are a "maker", they still have spaces left for exhibits, talks, workshops, performances, whatever.

My cube project on hack-a-day!

One thing I've been procrastinating about for a while is submitting my project to hack-a-day. I've been following that site for years now, so exposing my project on it to scrutiny from a hack crowd was a little bit nerve wracking. That plus it really still feels like I need to work on it some more, but I'll probably be saying that the rest of my life! Well I'm very pleased to say that I finally straightened things up a little and bit the bullet and the kind folks at HaD featured me today!

http://hackaday.com/2011/03/20/third-times-a-charm-512-led-cube-kicks-it-up-a-notch-with-rgb-leds/

Thanks to everyone for the kind comments that have been left already, It's really made my day.

Higher quality youtube clip of 8x8x8 RGB LED Cube/

I've had this clip up on youtube for a while but I think i forgot to link it here.

So here it is:

Hardware complete.

So after a few more hours of cutting and fitting, the cube is now hardware complete! ..

Pretty much anyway:) There might be a few more minor and cosmetic adjustments, like maybe i'll paint the ribbon cables black, or I might make a cover for that side of the box, but I kinda like the exposed look of the whole thing, nothing to hide.

I have to admit I think I botched the cable routing a little bit, the ribbon cables are much more of a mess then they have to be. The routing from the driver boards to the cube inputs is far from optimal. This is due to me changing my driver interface part way through the build. It's something that could definitely be solved in software, but I really can't be stuffed hacking the firmware anymore.

I also have to fix the power jack and maybe think about rubber feet, those ball end nuts might be a bit tough for resting on wooden surfaces. Apart from that, i'm planning to get back into the programming and work out some more patterns and maybe even some controls, like buttons, but that feels a little less likely at the moment. Will have to wait and see how I go.

Also, i need to get a can of air duster, it needs a bit of a clean.

Base progress

So I've painted the panels and got the electronics roughly in place. I've cut a notch along the edge with the cables, i think I'll either paint them black, or install a side panel to cover them, haven't decided yet. Next i'll actually fasten the electronics to the base and cut the main bolts to length to secure everything down. 

back to the cube

Finally got my butt back into gear to spend some more time with the cube.

I'm in the process of getting the mount completed and fixing all the electronics down. Once that's done, the only thing left will all be in software, so that will be great. 

Here's some pics of the mount in progress. I just used thread bar and nuts and washers.

I haven't yet worked out entirely how big the gap has to be between the top and bottom board. Once I mount the electronics, it'll be easier to see what the gap needs to be. 

Once i know what the gap is going to be i'll be able to trip the bolts to size. 

I'm actually extremely pleased with how it's coming up. It's quite a basic approach but I think it looks really great, has that utilitarian / industrial look. I have some flat black spray paint that i'm going to spray the particle boards with.

Should have some more progress photos over the next few days. 

in pictures

Here are some pictures, these are much better then the clips at showing how the cube really looks.

running code from 3dleds.com

here is a slightly better video clip..I have to work out how to take a better clip, this is still pretty terrible quality. It doesn't really do the cube justice at all. 

http://www.youtube.com/watch?v=C2dKcKZhF2Q

After i wrote the post yesterday a slight improvement occurred to me to the way I interpret the 3dleds code. The available code is in 8 bit resolution, but my cube runs at 12 bits. That means the code's maximum value is 254 but my cube's maximum is 4096. To overcome this, i just multiplied the code by 15. This was a very quick and dirty approach. It seems obvious now that a much better approach would be to instead use the code's value as a percentage and multiply my full value by it, this gives a much more faithful reproduction of the code's intended outcome.

I did this simply by declaring v as a float instead of an int and changing the line v = rawData[p]*15;

to this:

v = rawData[p];

v= (v/0xff)*0xfff;

explosion test clip

slightly better quality video of the explosion animation from 3dleds.com running on my cube.
http://www.youtube.com/watch?v=jlJ9fSPPUEc


For anyone attempting this for them self, I imagine if you got this far it probably isn't very hard to work out how to run these animations on your cube. If you've developed this for yourself like I have, there is no "standard" way to program these so there will no doubt be some tweaking you need to do for yourself.

For me, in my code, the entire cube is represented by a single data array:

display_array[NUM_ROWS][NUM_TLCS*16];

where NUM_ROWS and NUM_TLCS are number or rows and TLC drives respectively. 8 and 12 in my case.

All 12 TLCs are in series, the 1st 4 control RED, the next 4 green and the last 4 blue.

I also have a easy function called SET


static void set(unsigned char row, unsigned char channel, int value)
{
display_array[row][NUM_TLCS * 16 - 1 - channel] = value;
}//set



The trick is, my array is made up of 16bit "ints", however the TLCs only accept 12bit values. You can't make an array of 12bit elements, but my 12 bit values happily sit in 16 bit "ints".  Instead of trying "pack" the values into my array like some code I've seen, instead I strip the values out when it comes time to send them through the SPI module. I won't go into that here.

So, after studying the file description on the 3dleds site, I figured out that I would have to transfer the values row by row and color by color, AND frame by frame with a bit of a delay to control the speed of the animation.

All i then had to do was work out the offsets of data for each color, row and the "frame" and create loops for each. 3 colors nested inside rows, all nested inside frames. chr, chg and chb probably didn't have to be separate values, but it was easier to picture for me this way. I'm still only a novice programmer so you'll probably find this either not interesting, or already obvious.. But I like sharing so here it is:


int f; //frame
int r; //row

int chr; //chan r
int chg; //chan g
int chb; //chan b

int v; //value

int p; //position.

for (f=0;f<128;f++)
{

for(r=0;r<8;r++)
{

for (chr = 0; chr < 64; chr++)
{
p = chr+ (r*64) + (f*1536);
v = rawData[p]*15;
set(r,chr,v);
}

for (chg = 64; chg < 128; chg++)
{
p = chg+ 512-64 +(r*64) + (f*1536);
v = rawData[p]*15;
    set(r,chg,v);
}

for (chb = 128; chb < 192; chb++)
{
p = chb+ 1024-128+(r*64) + (f*1536);
v = rawData[p]*15;
    set(r,chb,v);
}

DelayMs(3);
}//for r

}//for f

8x8x8 RGB LED Cube test pattern explosion

I worked out how to play the test patterns available at http://3dleds.com/ and this is the result.

I still have some minor tweaking to do and I didn't finish work until late so it's time to go to bed, but i'll work on it some more in the next couple of days and take some nicer video of this and some other patterns! I'll also post the code that translated the raw hex files into something my cube could use.

I'll have to email the 3dleds guy to let him know how much I appreciate having those patterns to try out! It'll take me ages to work out how to make my own good patterns.

Let me just say one more thing: WOOOOHOOOOO!!!!

http://www.youtube.com/watch?v=_njo76C1QYg

8x8x8 RGB LED Cube controlled with PIC32 and some overdue homage.

HERE'S THE VIDEO!:

http://www.youtube.com/watch?v=2ohi4aGWeFs

The rest is a big long rant so feel free to skip it! ;)

So I've spent more hours then I'd like to admit during the last week trying to get this thing going, including a session until 3am last night but I am very happy to say I think I've nailed it! I've finally got some awesome TLC display driver software running on my PIC32. I've very pleased with my self, so much of what I've learned over the last year seemed to come together and it looks great! 

Don't get me wrong, there's still a LONG way to go ;) But this is a very important step. This is potentially the end of "hardware development". I do still have a couple of little bugs to iron out, but i'm pretty sure that's to do with cable routing and stuff which should be minor in the scheme of things. 

For anyone interested in the technical side, I wanted to try to get the cube to refresh at 100Hz, this meant I would need a layer refresh of 800Hz, since there are 8 layers, obviously. The TLC requires 4096 gray scale clocks (GSCLK) per layer draw so this means I needed a GSCLK of about 3.3MHz. 

I used Output Compare modules to generate the GSCLK and also the required BLANK and XLAT pulses at the end of EVERY cycle. 

This is something I came up by myself. The other codes I've seen always have a routine to pulse XLAT after the data has finished being sent. But after studying all the signals and with the help of my dad's oscilloscope which he lent me, i realized that my data HAS to send at every layer swap so there's no point having a routine pulse BLANK or XLAT, they just have to pulse at the end of every layer draw, full stop. 

So I have the three different pulses set up on three separate output compare modules, and the timer which they are synched to generates an interrupt at 800HZ which then sends the data to the TLCs.

At this point i'd like to say if I didn't borrow my dad's oscilloscope i'd still be guessing what's going on! That thing has been invaluable. Just to be able to see the waveforms and confirm what frequency they're running and stuff like that. I really couldn't have done this without it. Especially the waveforms made by the output compare modules, I'm sure if you decypher the datasheet it has all the details there, but at high frequencies where delays of one clock pulse can make the difference between 2MHz and 3MHz, Trying to work out exactly what the datasheet is trying to say and get it right to the single clock pulse with pen and paper, I just don't have the skill to do that confidently. 


If you are attempting something like this, or considering it, buy, beg, borrow or steal an oscilloscope, I don't fancy your chances if you don't at least have access to use one once in a while. This is something i didn't consider when I started this project. Fortunately, my dad has one I can borrow whenever I need.

There one other "main" thing to work out at this stage is whether the the way I have the "display driver" code running will allow enough cpu time to run "pattern" software as complex as I imagine i'd like to get it. Either way it shouldn't be terrible; either it can and it's fine, or it can't and I might have to enlist a 2nd uC for the pattern control. That would be another challenge but I think it would be fun too! There are some things I've learned about pic32 which make the idea of doing that no so scary. The main one being no separate DMA memory space! 

My "data" was too large to fit into the 2Kb of DMA memory in the pic 24 so the idea of shooting the data between two  chips was scary! It would double the amount of data the display chip would have to process, which pretty much defeats the purpose of processing the data on another chip. However the PIC32 doesn't have this limitation, so I theoretically should be able to send it the whole array at a decent refresh rate without the CPU taking a hit at all! 

Anyway sorry for the technical ranting.

Also at this stage I'd like to acknowledge some of the inspiration and assistance I've had over the last year. I've got a while to go yet but it's probably something I should have done a while ago. 

If you are thinking of building a big RGB LED Cube, this is pretty much a road map so far of the journey I've made.

First of the bat "chrmoe" and his amazing instructable:

http://www.instructables.com/id/LED-Cube-4x4x4/

This is what really got me started in LED cubes and microcontrollers. I've dabbled in electronics before this point, but never programmed a chip my self. I completed this project and knew straight away that this was just the beginning. So thank you very much chrmoe, you rule! 

I also have to mention the awesome folks at avrfreaks.net even though I betrayed them and moved to PICs. When I was doing the above project and experimenting myself with the code, the help I got from that forum was awesome.  The people there are some of the most helpful, witty and funny people I've come across a internet forum anywhere!

Two users in particular went way beyond the call of duty to help me out, JS and Kartman, thank you both!

Next is the 

http://www.hypnocube.com/

This thing is awesome! This is really what inspired me to build my own RGB cube. I still had no idea how I was going to do it, but I knew I had to give it a shot! My cube assembly is pretty closely modeled on the build documents available at the hypnocube site. I came close to buying one of these but really wanted the challenge of doing it for myself, plus i wanted to go BIGGER!  If you don't have a spare year to waste ;) then this is the way to have your own cube without developing it from scratch. It's easily the nicest RGB Cube i've seen for sale. 

Then I found Dave Clausen's LED Cylinder.

http://www.nycresistor.com/2008/07/26/led-cylinder/

This project is what I based my basic control design on. Using MOSFETs on the high side and TLC5940 LED drivers. Also seeing his code helped in creating my software. 

Next acleone and his Arduino TLC library. 

http://code.google.com/p/tlc5940arduino/

This code is really what got me started on the control software. First I ported this to straight AVR and eventually to PIC24. Not much of the original code is there, but the process flow is similar. Now I've moved to PIC32, the code has changed substantially but I wouldn't have been able to do it without what I learned from this code. 

Last but not least Matt Padina and his book 

http://sites.google.com/site/artcfox/demystifying-the-tlc5940

Which was pointed out to me only recently by someone who had read this blog. This document was really the icing on the cake! It came at precisely the right time and gave me precisely the right information. It let me rewrite a few key issues in my code and make it heaps more efficient. Without it i might still be struggling to get the PIC32 up to speed. 

So to all of the above, thank you very much! If I've forgotten someone please forgive me, i didn't get much sleep last night ;)

PIC32 Starter kit reference code for TLC5940.

Well it's taken me about 3 nights worth of mucking around but I've finally got some reference code for the TLC5940 working with the pic32 starter kit.

Because of a few things I've found out since I got the pic32, I've decided to write the TLC control software from scratch, instead of trying to port the program I've already got straight in.

Now when I say "write it from scratch," I do mean of course copy it from other code I found

When I say "I found," I mean someone else found and told me about it, lol, thanks very much Jason!

Jason pointed me to this document
http://sites.google.com/site/artcfox/demystifying-the-tlc5940

This document has been really great, if only it was around a year ago. I hope the guy puts some contact details so I can thank him. Also i'd like to ask him about licensing, since the BSD style license requires I leave his header on the file which pretty much attributes the software to him, but I didn't really even start with his file so i'm not really sure what happens now. I admit I've pretty much copied the process flow which he describes but the vast majority my code is different, so i'm not sure what that means. He uses the document to SHOW you how to get the code out of the process flow of the TLC so that's what I've done. I can understand if this was like a big program with lots of custom functions, but if I was to start from scratch now and write the program myself, i mean it's still a TLC chip so there's really only a couple of logical ways to implement control. If you got a few people to do this exercise, no doubt most would result in something pretty similar to the code in the document. At this step right now I probably wouldn't have a problem putting the author's name on it since this document has definitely helped me, but later as I build on it and I've added to it and copied some of my old code over, it won't make sense to keep attributing the original author,

Anyway, what he's got is for an AVR micro, so it has still taken considerable work to rejig it for PIC. So i'm just going to share my code. I'm not into "licenses" or anything yet so anyone can use this code for anything, i don't really care. If you do use it and find it useful it would be really nice if you could let me know, that's all.

This is really just "test" code. it isn't useful in it's current state as anything except to test that you have everything configured and plugged in correctly. If you are doing anything with the TLC I recommend you read the above document.

This is the end result of the code

Now I'm working on getting timers and interrupts configured. I'm actually finding it a bit confusing since there is a lot of compiler specific things going on which I have no idea about. For example, in the PIC32 reference manual for timers, they have an example of an ISR (interrupt service routine). Now NOT only is the document LOCKED so you can't even copy and paste, but they use a FONT where 0 and 0 and 1 (one) and l (lower case L) look almost identical! Now in a blog post you can probably guess the context and if you guess wrong, who cares, but in code, that you can't even copy and paste, it makes a BIG difference!! 

Not only that! But even after working this out I still couldn't get the blasted code to work. It wasn't until I came across other code in another example that I got it to work. If you have this problem, look for a document called:

 32-bit-Peripheral-Library-Guide.pdf

The problem was somewhere in the interrupt configuration, I haven't worked out exactly where yet because the 2 examples use different approaches in their configuration. This document has actually been a big help. It's supposed to be in the MPLAB docs directory but I have 2 MPLAB installs, one from pickit2 and one from pic32 starter kit and I do not have that document, it's not even on the microchip site from what I've found, I found it somewhere else. Anyway, it's good! And the code examples there actually worked for me!

Anyway, i'll post some more when i have the TLC working with my ISR code.

Also I don't think you can directly upload to blogger so i'll put the code up on my google site and link it here a bit later. 

Message to fellow cuber.

Hey Jason. Thanks very much for your comment on my post below. I mainly write this blog just for my own amusement and to show the occasional friend what I'm up to. Sometimes I do wonder if anyone else has ever actually looked at it. ;)

You raise a few interesting points I'd like to comment on so I'll just point them out, otherwise this'll turn into another massive rant:

Nine layers? Wow, well you're braver then me! :) I did at first consider doing something different, like a sphere or pyramid, but the more I looked into it, the more I realized there are some pretty good reasons why the 8 cube is so popular. Maybe most significantly eight is a "byte" and a power of 2. So is 64 and so is 512. Having 8 layers to multiplex, and 8 "blades"  becomes extremely convenient when you start mucking around with the data. There's 12 TLC chips, there's 12 bits per channel, there's 16 channels per chip, there's 16 bits per SPI send, they all divide nicely into each other. A central axis does indeed sound great, but an odd number of LEDs means you'll constantly have an odd "left over" bit (or bits) to deal with.. Don't mean to scare you, I'm sure there are probably ways to deal with this, maybe without too much trouble, but it was more then I thought I'd be able to tackle.

Sometimes when I'm feeling a bit bummed out about my project, it occurs to me that If I had started  a 4x4x4 RGB cube, it would almost certainly be finished by now. There will definitely be highs AND lows, so don't let that discourage you.

Multiple microcontrollers are also probably not impossible, but as you note it adds a whole layer of complexity. If you can sort out the synching issue, it might actually not be that big a deal, but you'd need to invest a bit of time just to find out. It might just be a matter of synching everything to an external clock. The slaves can "draw" the cube fast as they can, but it doesn't mean the "animations" have to be that fast. I actually think it makes more sense to keep the animations at 24-30fps or so, even if you can get your cube refresh up to 60hz - 100hz.  I'm yet to decide how far I'm going to try to push the pic32.

As for  moving to PIC, you might not have to! I also started my very 1st single color cube on an AVR. Back when I started the 8x8x8 project tho, there was no AVR chip that competed with the mid and higher end PICs. They had actually announced the xmega, but, let's just say, "good luck getting your hands on one of those" back then. However! That was a year go, and having a quick look at sites like http://www.evilmadscientist.com/article.php/xmega seems like they are around now! So, that's definitely an option for you. It'll be a little bit of a move from arduino, but not "that" much, I ported the acleone arduino TLC code to "straight" AVR without too much trouble, easier then to PIC that's for sure. (If you haven't seen that code yet by the way, you must have a look at it http://code.google.com/p/tlc5940arduino/ I found it a massive help and I wasn't even using arduino) Also, the avrfreaks support forum is awesome! I mean really awesome! Compared to the microchip forum.. No offence to the people on the PIC forums, I've talked to and got help from some amazing people on the PIC forums, but the format is just not as friendly for someone like me; it's quite technical, broken up into a hundred sections, fairly "formal" which is probably great for people who actually work with PICs. But the AVR forums are just amazing, more informal, only a few main sections, very "hackish", very involved, people have a great sense of humor, that's definitely the thing I miss the most about leaving AVR… Far out, reminding myself about this makes me think I probably should have looked into xmega again, before jumping into pic32! Oh well. ;)

Another thing i came across which convinced me I needed more processor power was this site http://lumisense.com/?page=eightcubed you might have seen it. For their "version 2" they actually use an intel ATOM processor, which is essentially a PC, running linux. Don't ask me how they actually interface the cube, i have no idea. :)

Cheers for the link to your site, http://www.photosbyjasonsmith.com I'll definitely keep my eye on it. Good luck with the soldering, I still remember the relief I felt when I got to the end! Put some music on while you're doing it, that really helped me through, and re-runs of Futurama. :)

Kicking it up a big notch to 32-bit with PIC32 STARTER KIT

So I have been working away on my cube for the last few months, whittling away at the issues I'm having. I installed a de-multiplexer to free up some pins and tried to implement the 2nd SPI channel, but it still felt like even in I squeezed everything I could from it, it would still fall short.. Don't get me wrong, I don't doubt someone could do it with a 16 bit PIC24, just not me. I still consider myself very much a novice programmer so there's only so much I can do with my limited knowledge.

One of the issues I recognized is that the TLC LED Driver can receive a serial signal (SPI) at 30MHz, but the PIC24 can only spit out SPI at 10MHz, this is something I didn't realize at the start because the PIC24 runs at 40MHz. I thought its SPI would run closer to that, it was only when I started playing with the SPI modules that i realized it didn't.

So, I was searching for options, if the TLC can receive at 30MHz, there must be something that can provide that, but I had no idea what. I suspect FPGAs probably do it, but I still have very little idea what they even are so that option's out. :) So the obvious thing seemed to look at what else PIC had to offer I notice their "top of the range" offerings, the PIC32, these chips are 32bit, 80MHz and can run SPI at 25MHz, not quite 30, but close enough! One BIG advantage of sticking with PIC is that the development is vary similar. I shouldn't have to relearn everything from scratch to port my program.

However there are several problems with stepping up to PIC32. Firstly and maybe most importantly, my "programmer" the Pickit2 which cost me, from memory, about $60, is not compatible with PIC32. Secondly, the silicon it self is considerably more expensive. Where as the AVRs I started on were in the $7 range, I could just about eat them for breakfast. The PIC24 were in the $15 range so still reasonable, not outrageous to buy 2 at a time, the PIC32s are more in the $30 range, so it's really time to start considering it carefully.

The bare chips however are surface mounted, which is not good if you aren't into SMT like me. Also you need a higher range programmer such as the ICD2 which is almost AU$250.. A good investment if you plan on doing a lot of projects, not so great if you plan on doing one or two.

Fortunately there is another alternative which is fairly decent for a hobbyist like me and that's what they call the "started kits". Basically you get a chip on a board, all wired up and hooked up and everything, but the really great thing is it has an extra preprogrammed microcontroller on it which acts as a debugger so you can program and debug the main chip with just a USB cable! There are a few options of these starter kits, with the basic one, which is still quite awesome, costing something in the order of $60. It's a lot smaller then I thought from the pictures on the microchip sites.

Unfortunately that's not quite all. This starter kit, all it has is a crappy high density socket on the bottom! I don't even have a clue what it's called.

The only way I've figured out that you can interface with this sucker is if you buy the "I/O Expansion Board" which sets you back another $80ish. So in all you have to fork out something like $150, which is still a hefty investment. BUT there are a couple of really great things about this, it's all factory mounted, so you don't have to worry about power, crystals, caps, programs sockets or anything like that, there are even 3 surface switches and LEDs which I definitely intend on using in my application, plus a couple of other great conveniences like probe points and a power socket.

So yeah, if you were going to be making heaps of projects and you etch your own boards and you solder SMT components blind folded, this is probably a bad way to go. But if you have one big labor of love project, and you need lots of processor power and you aren't great at SMT, then this is a really great option.

This is what it looks like all attached. The grid in the background of all these pictures is 1cm.

All the info and more about these products can of course be found on the microchip.com site.

So I'm not pretending I don't have quite a bit of work to do now, to port my stuff and learn about this new platform so I can get it all going again, but hopefully with the new power and flexibility, I'll get somewhat closer to completing this thing.

One last great thing is that all the starter kits are pin compatible, so even if i start with the basic one, and I want to buy the souped up usb starter kit II, which is about $80 and has the top of the line PIC32 chip on it, all I'll have to do is plug it in!

And if it needs saying, I am in no way affiliated with microchip.

controller roundup

I've decided to make a post outlining my control electronics and how everything is going.

Here is the power module i've been using from the start. 

i use an LM317T to produce 3.3v for my logic and a trim pot voltage regulated LM338T for my LEDs. i needed the extra current of the 338T as i expect my peak current could possibly be up in the 3A range, though i doubt it will get that high in practice.

Next is my control board. 

Up until recently I only had the one PIC on there but i've decided to try to implement 2, one will be purely the "driver" while the other will be used to generate and process the actual animations that will be displayed, hopefully taking that strain off the driver. Also in the bottom left I am planning to place a demultiplexer which will let me free up some required pins on my driver PIC. This will also let me get rid of the annoying "prog /run" switch i had to put in since I had to use two of the programming pins for my layer select bus. 

Lastly is my layer select board.

This is the one i'm least sure about. I'm using IRF5210 P-Channel mosfets as the layer current source. My main problem at the moment is layer ghosting. I've been reading that in this kind of application N channel is more suitable so i'm going to make another layer select board with N channel mosfets. The main hurdle is that N channel requires a gate voltage higher then source so i need to use mosfet drivers. I have almost everything sourced except for some DIP sockets and a couple of other bits. 

So all together and all plugged in it looks like this now:

Bit of a mess, but once it is all worked out, it will tuck neatly out of the way under the cube.

youtube clip of cube in action

Here is the youtube clip i promised.

http://www.youtube.com/watch?v=g7aDkQCx92Q

It has been way too long. 8x8x8 update

Well it's not because I haven't been doing anything! I've been hacking away for the last several weeks, trying to get back on top of this monster, but it hasn't been playing nice.

I was still suffering from the terrible interference type problem I've had pretty much from the start. Even with the ribbon cables and the fancy new custom PCBs, i was still getting a very noisy signal. Anyway, after hours and hours of analysis, i think I've finally got it going pretty well. The secret was to create a signal loop of all the control lines. Ok, probably obvious to someone who knows about such things, but I felt pretty proud of myself when I came up with it!

Anyway, the result is, a very nice test pattern, no noise, no distortion. The pattern moves, which you can't tell from the photo, but i might put a clip up on youtube soon.

old vs new

The pictures pretty much say it all.

Finally the PCBs arrive.

It's been a month since I ordered them, they were shipped on the 11th, but there was a mix up with the postage. At last the PCBs have arrived. Very excited to receive my very 1st custom circuit boards and they look great!