next topic »

[Reply #90 on:]

Thanks
Thats how I felt when I stared this thread many months ago. I had a working single color cube, it wasnt too hard to build...
Then I made all the wrong assumptions, and figured RGB wouldnt be to much harder. Boy was I wrong.
So far, the original cube has lit up LEDs, but is still not working, the next attempt is 1/2 way finished (less than the first attempt), the third attempt has been working great, I've done a lot of work documenting the building and testing modifying, and the last one seems to work, but is in the early stages of software development.

At this point my expectations are  that the unfinished cubes will be the best quality (speed/brightness), but they have also been the most problematic.

The quickest easiest to get up and working is the charliecube, If you use 75 ohm resistors, that should keep the LEDs under 20ma (although I'd recommend 50 ohm resistors as that should keep them at about 20ma, and 25ma on the red)

[Reply #91 on:]

I've been working on changing the 4x4x4 single color cube to work with the transistor cascade cube, and it requires radical change to the program.


This part should read in 16 bits (one plane of data)

Code:

memcpy_P( PatternBuf, PatternTable+PatternIdx, PLANESIZE );
PatternIdx += PLANESIZE;

The way the new cube works, it seemed best to deal with a whole cube data at one time, since I am lighting 1 line(4 LEDs), instead of 4 planes (16 LEDs).

I have changed it to:

Code:

memcpy_P( PatternBuf, PatternTable+PatternIdx, (PLANESIZE * CUBESIZE) );
PatternIdx += (PLANESIZE * CUBESIZE));

Hopefully, I've done that right, but there is another part where we use the data, this part:

Code:

digitalWrite( LEDPin[ledpin++], PatternBuf[patbufidx] & (1 << ledcol) );

Im pretty sure that what that line does is light up a specific LED (LEDPin is one of 16 column pins), and PatternBuf is the 16 bits of data, and patbufidx points to the specific bit for the specific pin. this gets looped 16 times to complete one plane.

Now what I want to do is light up 4 LEDs in a line, not a plane, each of the LEDs are RGB LEDs, so each bit will actually light all three LEDs so its white when on. Instead of lighting just one LED, I need to do all 4 (which is really 12 LEDs). Both ways do cycle of 16 to complete the cube, the old way did 4 cycles of 16, the new way does one cycle of 16, but lights 4 LEDs per cycle.

Code:

digitalWrite( RGBColumnPin[1], PatternBuf[patbufidx] & (1 << ledlevel) );
digitalWrite( RGBColumnPin[2], PatternBuf[patbufidx] & (1 << ledlevel) );
digitalWrite( RGBColumnPin[3], PatternBuf[patbufidx] & (1 << ledlevel) );
// LED 2
digitalWrite( RGBColumnPin[1+16], PatternBuf[patbufidx+16] & (1 << ledlevel) );
digitalWrite( RGBColumnPin[2+16], PatternBuf[patbufidx+16] & (1 << ledlevel) );
digitalWrite( RGBColumnPin[3+16], PatternBuf[patbufidx+16] & (1 << ledlevel) );
// LED 3
digitalWrite( RGBColumnPin[1+32], PatternBuf[patbufidx+32] & (1 << ledlevel) );
digitalWrite( RGBColumnPin[2+32], PatternBuf[patbufidx+32] & (1 << ledlevel) );
digitalWrite( RGBColumnPin[3+32], PatternBuf[patbufidx+32] & (1 << ledlevel) );
// LED 4
digitalWrite( RGBColumnPin[1+48], PatternBuf[patbufidx+48] & (1 << ledlevel) );
digitalWrite( RGBColumnPin[2+48], PatternBuf[patbufidx+48] & (1 << ledlevel) );
digitalWrite( RGBColumnPin[3+48], PatternBuf[patbufidx+48] & (1 << ledlevel) );
}
patbufidx==patbufidx+CUBESIZE;

I dont really understand the "& (1 << ledlevel) )" part in this case ledlevel is one of the 2 transistors that are controlling which line is active.  It seems to me that I dont want that in there, but its doing something like shifting a bit, and I dont know if I need it or not, or how to treat it in this modification. The variables ledrow, and ledlevel are what make this loop 16 times (4 sets for 4)
Since its lighting up 4 LEDs at a time, instead of looping through 4 planes, I changed the patbufidx++ to the above +CUBESIZE, is that a good way to do it?

[Reply #92 on:]

I could use some help fixing up this code to work right. The hardware tests fine with my other program, but I have been having no luck getting this one working right, and could use some help.

I've spent a bunch of time going over this code, and changing things many different ways.
I still havnt figured out how to make this program work with the transistor cube.

Most cubes are planar, but this cube is different. Its similar to the charliecube in that it treats the cube as 16 LEDs in a spires of 4 LEDs. Changing the program that runs 4 cycles of 16 cycles of LEDs,  seems simple enough to convert to 4 cycles of 4 cycles of 4 RGB LEDs,  

On my previous post I was trying to make the program load the 64 bits at a time, and it was making things crazy and complicated, so a couple days ago, I tried changing it back to 16 bits at a time, while lighting 16 spires/line of 4 LEDs, one spire/line at a time.

The way I was expecting the program to work is basically like this:

1 row pin and 1 level pin turn on a individual cathode for 4 RGB LEDs in a line (spire).

12 anode pins control the 4 RGB LEDs. To keep things simple, we are treating each RGB LED as a single color LED, and using 1 bit per LED

This code includes 3 versions of the anode pins that use a  "1 << variableName" thing,

The program starts with the usual declaring variables, and setting up the pins, then starts a couple loops and has some while statements. The loops used to be 16 and 4, but I needed to change it to 4 and 4 with 12 anode writes instead of 1 anode write.

The original version has a pattern buffer index that points to one of 16 bits of data, and it increments until it completes its cycle, then advances a plane, and reads in and processes that 16 bits. It does this 4 times to complete 1 line of data (64 bits).

Im trying to make this program cycle 4 lines of 4 LEDs at a time, then increment the pattern buffer index 4 times, which should be the same a sequencing 16 LEDs on a plane (4 lines of 4 LED is the same as 16 LEDs in a 4x4 matrix)

I have found that if I comment out the pattern buffer index, I can get things to start to work, but never quite right. Sometimes it lights up many LEDs instead of one, It only seems to read the first 4 bits in a 16 bit segment though.

If I enable the pattern buffer indexing lines, the cube lights many leds on many levels, its really weird.

Heres the current not working quite right version. It only has  a couple lines of data I just change the data with 1s and 0s to test that I can control each LED one or more at a time.

[Reply #93 on:]

It says the code too many characters for one post Splitting it seems the best option.

Click on Additional Options (lower left of text window) and Upload it as an Attachment.

[Reply #94 on:]

Program attached as text file.

Yay! Thanks Runaway Pancake!

Edit: replaced ugly program with more tidy program.

[Reply #95 on:]

I went back through the code, and cleaned things up, and wrote better comments, and changed the data a bit. it now has a small sample of spinning and flipping planes of LEDs.

This cube uses 20 transistors(2n2222), and 20 resistors(8 270ohm 8 100ohm, 4 150ohm), and 64 RGB LEDs. I used 2n2222 NPN transistors with common cathode LEDs, but it can be built with MOSFETs instead of BJTs, it could also be built with ULN2003 chips, or even a combination of MOSFETs, BJTs, and/or ULNs.

If you have common anode LEDs, you will need to use PNP transistors, and change the code a bit (turn HIGHs to LOW, and LOWs to HIGH.

[Reply #96 on:]

I modified the program to change colors each time it completes the cycle.
There are 2 version of the color cycle program, version cycles through:
Red
Blue
Green
Yellow
Purple
Teal
White

Version 2 is more like a color wheel, or rainbow where colors

Yellow
Red
Purple
Blue
Teal
Green

It could be easily modified to do random color(max 7 colors). each cycle.

Getting more colors will be difficult, there really isnt hardware PWM support  (there is, but only on a few pins, not enough for the whole cube) This cube is directly connected, not serialized, so you cant do SPI. I think you can get some color mixing, but its not too simple.

[Reply #97 on:]

hippynerd,

In another Subject you posted that you had some questions about transistors, hfe etc, that went unanswered and that you wanted to discuss them here.

[Reply #98 on:]

Yeah, I do have some. It has been a while since since then, so I cant remember exactly what details, but it mostly had to do with finding the right resistor to use. With the BTJ types, you need a base resistor, and part of the calculations require figuring out the gain or HFE (I think thats right... its been a while). What I ended up doing was build a test circuit with all the parts that I planned on using, and guessed for the base resistor. Then I measured, and changed the resistor, and measured again. I did this several times and it seemed that anywhere between 150 and 300 ohms was safe for a base resistor.

I found many graphs and stats on the datasheet, but I couldnt figure out what to use for gain. I cant find the datasheet, but the part is a 2n2222, in the sot23 package. I thought it was linked in this thread, but I cant find it.

I also have some mosfets. As I understand it, I dont need a resistor between the microcontroller and the gate, but I do want a resistor between the gate and source, and I think that it is there to help it switch off faster? I think I got some 5ks for the mosfets.

If you could help clear up how I should calculate the resistor values, that would be great.

Im still kind of unclear on how to figure out decoupling caps, but it seems like there are only a few values commonly used for that, and trial and error may be good enough.

[Reply #99 on:]

OK

The beta isn't given on a graph, it's a figure inside a range. 
They don't vary widely, and they've got better over the years, but each device is different.  [There are such things as "matched pairs", more expensive, and matched quads in DIP/IC packages.]
Designers assume maybe the "typical" or work with the specified "minimum", when beta is important.  Avoid "beta critical" designs.

Some "rule of thumb" figuring:
Collector current cannot be greater than base current * beta
You can back figure beta by determining where collector current starts to poop as base current is decreased.

With a "common emitter" circuit, base current = (input voltage - V_be) / base resistor).
Collector current (Max) = Vcc / (base current * beta).  Your design demand should be less than "max".
A transistor isn't a perfect conductor, that's why it's called a "semiconductor"; there is a voltage drop from collector to emitter (V_ce) - as current increases, V_ce increases.  So, be prepared to take that into account.  In our "common collector" circuit, V_cc gets divided amongst the LED, the resistor, and across the collector-emitter junction.

Emitter current = base current + collector current
(When collector current is much more than base current, I_c approx = I_e)

So, some transistor has a beta of 50.  If it's actually more than that, that's OK.
Let's say the goal is 50 mA collector current. 
If everything was ideal we could go with 1mA base current, but anticipate more.  With 2mA, then 100 mA collector current is possible, but that's "capacity" kept in reserve, a buffer, it's room to spare.
More base current than necessary should be provided while not over-doing it.  That's a "judgement call".  2X? 4X?  (V_ce * I_e) < P_d.

That's a presentation in a nutshell, but I think it sheds some light on the matter.

[Reply #100 on:]

http://www.fairchildsemi.com/ds/MM/MMBT2222A.pdf

I think this was the datasheet I was using.

The 2n2222s are for a cube that lights upto 4 RGB LEDs, assuming they are 20ma, then that means I need between 0 and 240 ma (12x20=240) for the LEDs, but that doesnt account for dissipation by the resistors or transistors in the circuit.

From what I can tell, if I use too much base resistor, it may limit current too much. and not sink enough current, which may make it not light up enough, too small of a resistor, and you risk drawing too much current from the microcontroler.

With the mosfets, you dont seem to need that resistor, or is it just under some circumstances?

I have 2 cubes that will need mosfets for turning planes on and off (both cubes are 4x4x4 RGB, and use a 4 plane setup for a 25% duty cycle. Each plane consists of 16 RGB LEDs, assuming 20ma, that totals 16x60=960ma, or about an amp.

One cube sinks, while the other cube sources, so I picked out an n-channel, and a p-channel.
Heres a link to the n-channel.
http://www.diodes.com/datasheets/ds30830.pdf

and heres a link to the p-channel.
http://www.digikey.com/product-detail/en/AO7401/785-1085-1-ND/1856028

In post #77 I talk about how I come to think that this will be a good part, and in post 81 I list the parts that I ordered.

As I understand things, the fets wont need a gate resistor (similar to a base resistor), but it will work best if I have a gate/source resistor (makes it switch faster?). I also read about ringing, and that you can have a ringing issue that may damage the fet, the resistor reduces ringing?

When you talk about a beta, is that the same as gain, or HFE as I've read in other documents?

It was quite a bit of effort trying to figure out the right parts. I had to read a lot of datasheets and try to compare values and such. Digikeys website helped, but even then I spent hours. It would be nice if it were easier.

[Reply #101 on:]

I'd like to stick with transistors ("bee-jay-teez"), that's supposedly where you weren't getting support.

Beta is h_fe, Yes.
I'm still assuming that the "common emitter" circuit is the basis of this discussion.

As for "dissipation by the resistors or transistors in the circuit", remember: current is the same everywhere in a series circuit.  Let's do one thing at a time and not get caught up in a manic death-spiral.

If you want the transistor to do 240mA, then let's figure 300mA, plan for more than is needed. 
I think that a beta of 50 is a good assumption.
300 mA / 50 = 6 mA
So, with "5V" as input voltage to our humble transistor, (5V - Vbe )/6mA = 4V / 6mA = 667Ω. 
So, we'll live it up and go with 470Ω, working out to about 8 mA.

If V_cc is 9V, and I'll venture that V_ce might approach 300mV, then 9V - 0.3 = 8.7V. 
8.7V / 240mA = 36Ω. 
3 100Ω in parallel gets you 33Ω, resulting 263mA.

So, set that up, starting with > 2K for that collector resistor.  Measure the voltage across that resistor.  The voltage across the collector / the collector resistor Ω = collector current.  Replace the collector resistor with a lower value, paralleling for value as necessary, taking notes along the way, till you have several data points that you can analyse. [2K, 1K, 500Ω, 100Ω,...]
If you can manage with the milliammeter then go that route.  Voltmeters make you get out the calculator, but they don't blow fuses.

The absence of an LED in the circuit doesn't matter, as we're just looking at, discussing, the collector current thing.

[Reply #102 on:]

I think the primary issue I had was trying to figure out the beta, or gain as others called it, when I asked. One person told me to assume a gain of 100, another person told me to assume a gain of 10, and I was unclear on how anyone comes to the conclusion of a good number, both seem to be guesses, and radically different guesses at that.

I looked over the datasheet to try to figure it out. There are several graphs and several tables of data, but I couldnt figure out which one is the correct figure. If you do the calculations with each figure, you get very different results, and I couldnt rely on any of those calculations to be even close.

It seems to me that the part has a specific beta, you shouldnt have to guess if its 10, 50,100, or whatever. I do understand that at different temperatures, the beta will vary, but at or near room temperature, they should be should be pretty consistent.

Your first calcluation, with the 50 beta estimate is for the base resistor correct? That resistor goes between the arduino, and the base on the transistor, correct?

The second calculation you posted you said was for the collector resistor, Im not sure how/what/why that is about. Is that a resistor between the collector, and ground?

With the base resistor, I basically made a guess, then made some calculations, then tried a few sizes of resistors, making notes along the way. Because I was cascading them, I ended up testing them in tandem, as well as single.

It seems to me that I should have been able to get it a lot closer with the calculations, but having to guess with the beta made the calculations seem pointless.

I should look for my voltmeter, I havnt seen it in like 20 years. Measuring was very difficult, since my minimum was 20ma, and my max was 240 ma, I couldnt use one setting to measure all conditions, and that made measuring relatively inaccurate.

In your second calculations you have 9v -.3, should that be 9v-.7 (saturation voltage)?

When I was doing my testing, I only measured current, but I measured it at a few places.

It would also be good to understand why we need a resistor. its my understanding that he base resistor can be used to limit the current to the collector, but its primary function is to limit the current on the microcontroller, without it, you may draw too much current and break the microcontroller. Is that a fair statement? is there more too it?

[Reply #103 on:]

I've started a couple of schematics. Before I put all the wiring in, its a bit easier to understand so Im including these views, that really only show how the transistors relate to the cathodes on the LEDs.


I've just added the full version. The schematic is kinda weird looking but its complete.

The BOM:
64 CC RGB LEDs
20 2n2222 transistors (I used little SOT23s)
20 Resistors 8-270 Ohm, 8-100 Ohm, 4-150 Ohm
40 pin sip socket (to connect arduino)
Arduino (I used a Nano, but any should work)
Runs on USB or alternate 6v power supply.


Edit: removed incomplete drawings, The full drawing is about 2,000x2000 px, its kind of big, but reducing it made it too hard to read.

[Reply #104 on:]

Heres a schematic for the charliecube spire, its not the whole cube, but if you can understand one spire, then multiply it by 16, you are most of the way there.

Edit: Changed drawings, included both common anode and common cathode.