RGB Cube Update 1

This past week offered up revisions on the schematic design after being looked over by a manufacturing test engineer. Since he had pretty much no part in designing the schematics, he was perfect for a review. He carefully poured over the datasheets, and came up with several changes that have helped improved the schematic design.

1. Pin 3 on the CD4051B (3:8 Demux) was tied to high, so that a pin was freed up on the microcontroller.

2. Vee and Vss were tied to ground, not 5V like I had originally misunderstood.

3. The connection between XERR and gnd was broken.

4. Provided breakout jumpers so that if one still wants to program EEPROM, one can simply change the jumpers for a given PWM driver and program it.

5. Broke up the PWM drivers into 2 circuits. We kept the first 2 on one circuit, and put the last 2.5 on a separate circuit. This took the number of bits that we need to bit-bang per layer from 72 * 12 down to 40 * 12, offering up about a 45% improvement in speed. So now every layer has 2 serial input lines.

One concern we realized is that there is a great risk for fan-out. One microcontroller was going to be trying to drive upwards of 120 chips, while only being able to output 18mA at max. This was going to be a massive problem, one that was solved by providing the 74LS240’s or 241’s on each panel, offering up a buffer to help push that signal to all the panels. I am unsure, as of right now, exactly how to set up the devices between the chipKIT and the layer, but I should have that next week.

We are also looking at providing 2 power supplies. One power supply will be used for just driving the transistors. The other one will be used for all of the logic. We are hoping that providing a high and low pass filter can mean that this cube only needs 1 power supply, and can handle both signals, but the resulting noise may still be too much for the logic chips to handle. Further testing will be required.

I also have some more details about the software. As I mentioned last post, I was going to be using a 3D array of a struct called Pixel. Each Pixel will hold a 12 bit value representing the PWM clock value. Also in the software I will be providing arrays for color balancing. If someone wants to update a color to a certain level, they would set it by saying something like RedBrightnessLevel[12], and now that value at index 12 will be the value stored in the red value at a given pixel. The highest brightness level that we will be providing (with the exception of a possible strobe effect) will be about 70% of the original brightness level, so that it is easier to bear staring at the cube for long periods of time.

After talking with Microchip, their MPLAB X IDE does not yet support the chipKIT, our microprocessor of choice. We will be using the MPIDE, the Arduino and chipKIT compatible IDE modified by Microchip. We will be needing to use direct port writing. Some tests have revealed that MPIDE can toggle a pin at a max of 2.5MHz, which we need significantly faster than that if we are to have any progress made on this. Aside from other requirements, the PWM driver datasheet provided a couple of formulas to calculate minimum frequencies for the PWM clock and the Serial Clock. These formulas have revealed that the PWM clock needs to oscillate at a minimum of 245.76kHz, and that the Serial Clock needs to oscillate at a minimum of 28.95kHz. The PWM clock will be set to oscillate at 500kHz, and the goal for the Serial Clock will be 30kHz.

We are planning on using interrupts and timers to help regulate these speeds, while still being able to do other functionality, like serial communications. The highest priority interrupt will be the PWM timer, which will toggle a pin on timer overflow. I have not yet determined whether I want to directly control this, or use an output compare module to toggle a pin. The next highest priority interrupt will be updating the serial clock. This interrupt service routine will calculate the next set of values to clock out to the PWM driver if it hasn’t already, output these results, and clock the SCLK line. It will also be used to handle a case when everything has been updated, and it is time to shift to a new row. My goal is to be able to precalculate the next set of values, and then just have the ISR output this. However, the serial lines coming in will take priority over this calculation inside of the main function.

Finally, this week has also produced a bending guide, which will be used to ensure that the LEDs are all bent the same way. When assembling this cube, it will be nice to have consistent LEDs that we can just solder together. See the bottom of this post for some photos of the bending guide. The bending guide offers a tight fit to the LEDs, and ensures that these can only go in one direction. The legs are then bent appropriately. The one lead that goes away from the other leads is the power lead, which gets it above the other leads.

Other than that, no new news has come out of the past week. More updates to come!