I just started working on a new project... As soon as I get it a bit futher I'll post up some video/pics... Here's a run down...

After seeing the tutorial on the LED sign I thought it was really cool... I knew that it was fairly simplified in order to be easier for newer nerdkit owners to be able to accomplish and understand. But then I thought to myself... SELF! How cool would that be if it was much bigger?!? How cool would that be if it would take a list of "things to say" and repeated through them instead of relying on serial control to constant input info? How cool would that be if it could do animation effects? etc...etc...etc...

So with that said, I decided, "How cool would that be if I MADE it do that?"

So that's what I intend to do... So here's the basic scope of the project...

1) It must be a wide display, since I've got at least 200 LED's sitting here, I decided that it would use 200 of them... I decided on 5 lines (like the nerdkit one) which means that I'll have 40 columns of LEDs...

2) It must only utilize a single MCU... Companion ICs are okay...

3) It must be bright enough to show up well even in daylight, yet it must utilize only standard (i.e. cheap) LEDs, no superbright/high current LEDs...

4) It must be able to repeat at least 5 "sentences"...

5) It must be able to run stand-alone...

6) If the "sentence" will display within 40 columns, it should be able to verticle scroll.

Since defining the project I set off to try to figure out how to accomplish all of that... I think I've finally got it all sorted out... In my head anyway...

So here's a brief rundown, and I'll get a schematic posted up once I get it made up...

I'm going to use 5 I/O pins for the rows... And only 1 I/O pin for the columns... Meaning only a total of 6 I/O pins to drive the entire thing...

In order to accomplish that, I'm going to use 5 4017 Decimal/Decade counters. They will all be cascaded together driven by a single "clock" (the 1 I/O pin)... Through cascading I should be able to get 9 I/O's on the first counter and 8 I/O's off each successive counter. Technically giving me the ability to drive 41 columns, but I only need 40...

Because I need to to be "bright", each row and column will need to be driven via a transistor... I'm going to use N2222A's because I happen to have a ton of them... That means a total of 45 2222A's will be used... (again, one for each row and one for each column).

I spent several hours trying to come up with a way to "divide" the rows in half, like the nerdkit LED but placing them parallel but opposite to each other... That would reduce the number of counters and transistors needed... The problem is, I spent a few hours trying to come up with a way to "switch" the rows from source to sink, but alas finally gave up... The best I could come up with was utilizing another I/O off the MCU to toggle a flip/flop... The problem is, just like with the MCU, the flip/flop won't sink/source nearly enough current to drive what I need... That means a transistor, and the only way that would be possible would be if I could "switch" the transistor from NPN to PNP... I did come up with one model that used one of each (PNP and NPN) in parallel to each other, which I believe would work, but that creates another issue... I'd have to do the same thing with the row transistors as well... So it would still require 40 transistors for the columns, and now 10 transistors for the rows... 25 NPN and 25 PNP... Since I didn't have that many PNPs, and the fact that this would make the circuit much more complex, I decided that it wasn't a fair tradeoff to save 2 4017s... Especially when you consider adding a flip/flop...

To deal with the brightness issue, my plan is simple... Since each LED will only be doing a 1/40th duty cycle, and I want each one to be driven at 20mA, I'm going to drive the rows with 800mA... That will actually drive each LED with less than 20mA given the time period in the "off" state while shifting out the new row settings... I haven't calculated out how much time this will take, so I'm not sure exactly what that calc will be... Before building it I will to make sure... If it's too much of a reduction, then I have a backup plan for the rows... I'll drive them with a 4894 shift-store register. This way I can leave the current column driven as is while loading up the bits in the rows for the next column... The clock to turn on the next row will also switch the row bits in place. That would make a real clean solution, but I don't have any 4894s on hand, so I'd have to order one... So I won't be using that unless I calculate I need to.

As for the serial, that will be pretty simple... Initially it will go into a "listen" state where it's ready to take a stream of data from the link. Just like the nerdkit LED sign... However, a certain control character in this state (probably a BREAK) will enter a menu system. Within the menu you will be able to display up to 5 lines of "sentences"... Each line can be selected and "re-entered"... Each line that is short enough to fit within the 40 columns will also have a "vertical" option. Each line that is entered in will be stored in the EEPROM. Upon boot it will wait 10 seconds for "stream" data from the serial and then automatically begin cycling through the 5 sentences... If the vertical option is turned on, the "sentence" will scroll from the bottom up, blink a couple of times, and then continue to scroll on up and off the screen. Control can be taken back at any time via serial. The menu will also have an option to clear all 5 sentences.

The LED's will be spaced 3/4" apart... I believe that's the spacing the nerdkits one used, and that's what I figured would give the best appearence. This makes the total display area about 30" wide by 3 3/4" tall.

It's gonna be a fun little project and again I'll post everything up as it progresses for anyone that wants to try it.

If you have any thoughts / comments / opinions / suggestions, let me know! Thanks!

Sorry, meant 4094, not 4894 above...

Hi rusirius,

that's a great project! I wanted to make a LED sign of my own, but I never got to it because I am tied down with my alarm clock. Anyway, my overarching idea was this: since we are not trying to avoid the board-to-PC connection, it is going to stay there, so why not use it to its full potential? Why not make the sign completely pixel-oriented instead of trying to cram character generation on chip?

The calculations are simple: 200 LEDs = 200 pixel bits = 25 bytes per frame. Let's add two more bytes to encode the number of milliseconds this frame is to be displayed.

At 115200bps, 8N1, we can push through around 425 such frames per second — more than enough for streaming content! But at 27 bytes, frames are small enough that we could upload a whole bunch of them in advance. One kilobyte of RAM could store 4.5 seconds at 8fps. Toss in an EEPROM chip or two from defunct stereos and TV sets, why not, and we'll get a truly portable LCD marquee.

All right, you can tell I am making this up as I go, but my main idea is this: why not just use pixel-based encoding and delegate all the character rendering, effects and animation to the host computer? Imagine writing a simple "gif2lcd" utility that takes a monochrome GIF89a animation and converts it to a series of 27-byte frames You'd be able to make your animations in just about any graphics editing program.

Cheers, Zoran

P.S. I understand that your approach aims for greater autonomy for valid reasons; you do want to be independent of the serial port. While my idea does provide for such autonomy, it does that in a different way which may well be quite the opposite of what you want.

Hello,

I've done the "simplified" version of the array ( i think you should try it first) and thought mine would look better in the corner across the room. A little bit of looking i found a wireless receiver capable of TTL data transfer from a bluetooth dongle.I'll should post it when i get it done.

Your way is ambishious but sounds like it's just a script loaded on the chip that you'ld have to reprogram every time you got sick of reading the same 5 phrases over and over. Zoran's idea above sounds good for getting the animation, i'm going to try that one myself. If your gungho on 40 collums go 48 and double it up to run as one.

This was not a easy tutorial, ask Humberto how many times i emailed him. And just to mention, i was on windows when i started, now i'm a swearing Linux user.:) But i got what i wanted, any feed i want going across the array plus numerous scripts. Endless entertainment.

farmerjoe

Wayward, That's a great idea, but I think I'll go for a blend of the two... Or rather a switching ability of the two... I already intended on it supporting 2 runtime modes (stand-alone, and character stream fed), so it wouldn't be hard to do a third mode that would support a "pixel" stream... Really it would just be a character stream, just 25 characters (bytes) at a time versus 1...

Farmerjoecoledge, Actually I have a pair of 418Mhz wireless tx/rx. I had them in mind for another project, but decided to switch to a pair of 2.4Ghz ZigBee transceivers. I just gotta perfect my etching process to get a good pad for them... (they're 5mmx5mm QFN package) My last effort would have worked, but not quite as perfect as I've had liked... I think I have a solution though... Just gotta give it a whirl.. Anyway, point is, I could use the 418s for extend the serial port to the sign... Only problem is since they're not transceivers I'd only have one way communication... I'd have to think about a way to make that more reliable...

I had a little time this evening to whip up a quick version 1 schematic... I haven't had time to go over it yet and make sure everything is right, so forgive any errors, but I figured it was better to get it posted sooner better than later... ;)

Clicky Clicky for .PDF

A quick note about the schematic... You'll notice I don't have the LED's directly on there, and instead used a 40 pin (cheap IDE cable.. Ha!) header for the columns, and a 6 pin header for the rows... I did this for two reasons...

First, when this is finalized and I go to create the PCB, I don't want the auto-router to have to deal with all that crap... Second, and more importantly, I don't want to have to place 40 friggin LEDs on the board... The "control" PCB will be pretty small, so it just makes more sense to keep everything "modular" like this.. As a matter a fact, if the refresh is fast enough (still haven't sat down to calculate it out yet) then I'll also have in the final design the positions and headers for a second board... In theory that could provide up to an 80 column display... OR, with a small programming change, add a second color... (i.e. 40 more columns of green LEDs.. I just don't have the parts to build that out yet... In fact, I'd have to see how it worked out, but if I REALLY wanted to go overboard I could add a third "blue" column... Two reasons I'm not even considering that at the moment... First, blue LEDs are ridiculously expensive, and second, if I'm not mistaken they take MUCH higher current to drive... I'd have to get some pretty large FETs on there... Even more money!! LOL...

Anyway, it's a start... I need to review the schematic, do the calculations, change schematic as neccesary, do a couple of tests to prove my calculations, then I'll get the PCB laid out and etched... Should be able to get the first version up and running pretty quickly...

Hrmm... just had another thought.. Since I was thinking of possibly adding wireless to this anyway.. Anyone have any experience interfacing with the Wifi (802.11x) stuff? Might be worth looking at getting this thing on the net with WiFi.. ;)

Just about to take off and realized something... Might be nice of me to describe the cascade arrangement of the 4017s for anyone not familar with them or anyone without much electronics experience...

The 4017 is a decimal (i.e. 10) counter... Each clock pulse that is sent to the CLK input will "increment" the count and make the next "bit" high... Q0 through Q9 represent the bits... When initialized the output is 0 (Q0 high), the next clock pulse will drive Q1 high and drop Q0 low..., next clock pulse, Q2 goes high, Q1 goes low, etc..

Generally these are "stacked" in such a way that Q9 will drive the CLK input of the next 4017... (making it the "10s" place...) It's Q9 can drive the CLK of a third 4017 (100s place) etc...

In the configuration I have them in, here's what happens...

They all come up with Q0 high... The Q9 on each 4017 is fed to the input of an AND gate as well as the ENABLE line... I'll explain that in a moment...

The first clock pulse comes in... It is sent to the CLK of the first 4017 and all the AND gates afterwards... Since all the OTHER sides of the AND gates are low, none of them trigger an output.. So only the first counter increments...

The count continues up until Q8 of the first 4017 is high...

The next clock pulse that comes in makes Q9 of the first 4017 high... That output is fed to the OTHER half of the first AND gate... Since the counter triggers on the RISING edge of the clock pulse, the CLOCK is still high after Q9 goes high... That means the AND gate turns on making it's output high... That output is fed to the CLK of the next 4017... At the same time, the high state on Q9 brings the ENABLE line high which PREVENTS that counter from incrementing...

So now each clock pulse will carry through to the second 4017 until it's Q9 goes high... When it does, the same chain happens, one side of the AND gate goes high, the other side is still high from the pulse, and that feeds to the next counter... at the same time, that Q9 also disables the second 4017...

This process continues on until we get to the last counter...

When Q8 (not Q9 because I only needed 40 outputs, not 41) goes high, it goes back and pulls the reset line on the first 4017 high... That in turn makes it's Q0 go high (which drops Q9 low, preventing counters further down the line from trigger because of the ANDs, as well as dropping the ENABLE so that it can start to count again...) Q0 is also fed to the reset of the next 4017 which brings its Q0 high, feeding the next reset, etc... right down the line bringing everything back to it's initial state.

In talking this over to myself, I just realized I'll probably also throw an I/O pin connected to the first reset as well, this way I can manually reset from the MCU if I want/need to...

I'm not nearly as elegant as the "nerds", LOL, but who knows, maybe they'll see this and decide to do a tutorial on counters and maybe a couple other useful ICs that can be combined with the MCU to do some really cool stuff!

Since I'm waiting for my receivers to arrive you got me going. IEEE 802.11 (wifi) is the standard for wireless protocol or just plain internet. It's all wireless government encrypted data transfer. The 2.4Ghz ZigBee transceivers you mentioned are what cell phones use. If i'm not mistaken there's a difference i think mainly in the size or kind of data. What you and me need is the TTL not RF.

Now i'm wondering if i'm on the right track with the TTL data receiver. Just because it's supposed to act as the programmer does, a converter for the TTL data so uart can display it. Yes this would be only one way, for now, maybe later i'll get it to talk back. Hey,a woman i can press a key and shut up, how cool is that? Have a look see what you think. http://cgi.ebay.ca/ws/eBayISAPI.dll?ViewItem&item=300348350118 Keep us posted.

rusirius : wow, firstly an impressive concept. I have made one of the Nerdkits led Marquees and I'm currently making another, thats about my limit at present. This is going to be an impressive project.

Thanks for going into detail on your (proposed) design - as I was wondering how you planned to implement it all. I must admit, I think I'll have to read through your explanation of the 4017s a few times before I'll actually understand it.

I wish you all the best with this - keep us posted on progress.

Farmerjoecoledge : Let us know how you get on with the wireless, I've been wanting to do something along those lines, but having read a little, it seemed a bit too confusing.

One final thought - if you can control 216 LEDs, then you could make a cool 6x6x6 LED cube (or how about a 8x8x8 = 512 LEDs), I'd imagine the programming would be very tricky to get your head around.

Anyway - Good Luck!

-Steve

Steve, If you take a look at the schematic and follow along with the 4017 explanation you'll probably find it pretty easy to understand... Like anything it's a bit hard to wrap you head around if you don't have something to stare at... Or I'm like that anyway... ;)

On to the project... In my initial testing I've run into a bit of a snag, and I'll be the first to admit at the moment I have no idea whats going on... I can't quite wrap my head around it for some reason... I think maybe it has something to do with the characteristics of the 2222As...

Currently each row (only 1 row for testing, but other 39 are simulated) is being turned on for 690us at an interval of 2.76ms... That's my scan rate with 40 LEDs...

I'm driving the LEDs with a 12v 4.5A regulated power supply, so sag shouldn't be a problem...

The bases of the 2222As are fed from the 5v regulated supply... Grounds of course are bonded...

According to my calculations, when I first set out I adjusted the current limiting on the LEDs to drive at 500mA... Should be within the range of the 2222As considering the duty cycle...

My actual data however was WAY off from what I expected...

I was using 20 Ohm as current limiting... 20 Ohms across 12v supply, account for 2v drop across LED, and we should have 500mA...

However, my actual data showed about .24mA going through the LED... Now obviously the meter and wiring are factoring in some, but I didn't expect it to be anywhere near that far off...

So I started experimenting with various current limiting values... Each one gave me a boost, but eventually I ended up with no current limiting at all!

The wiring to the meter checks out at .1 Ohm... So in theory that means I should be pushing 100 Amps! Well, since my supply is only 4.5A, technically 4.5A... Which SHOULD be ~112mA through the LED!!!

But in reality, even with no current limiting at all, I'm only able to push 2.4mA through the LED... And I'm just not sure why!

In fact, I'm now driving the transistors (E-C) with NO current limiting at all...

Interesting... Well, I found my problem... Well, the first problem was I'm a complete bonehead... LOL... After screwing around with this thing for who knows how long, I happen to look up at my scope sitting right in front of me and realize, "uhhh, why guess???" LOL... Anyway, after hooking it up and having a look I found two interesting things...

My pulses are coming at intervals of 4.26ms instead of 2.76ms... I'm not sure how I screwed that calc up...

In the same respect they are lasting only 110us, not the 690 I expected...

Last but not least, my peaks are only hitting 3.6v...

Add that all up together and it's easy to see why I'm not getting nearly the current I expected... Hell, that means I'm running a duty cycle of 2.8%...

Now with all that said... I'm still not sure I understand WHY it's happening... I think the peak voltage is easy to explain... 110us is pretty damn fast... These transistors are fast too, but I could certainly understand...

What I can't wrap my head around is why the cycle is so short... I'm gonna throw a limiter in there and and cycle it on/off for EACH run of the loop and see what the times look like... That should provide a clue as to where I need to look next... ;)

Another quick update... I modified the program loop to toggle the LED on/off through each loop... I had clocked the loop to run at 57600Hz...

I'm now showing exactly what I would have expected in my waveform... with one exception... I'm showing a 50% duty cycle... That's perfect... I'm showing a 28kHz frequency... That's perfect... What's confusing however is that I'm only showing 5V... (well, 4.48v to be exact...)

Also, ignore my ramblings above... I realized after typing it that 2.8% is the duty cycle I should expect... I'm not exactly sure what I was thinking there... and of course I can't delete/edit it... Anywho....

So now I gotta figure out why I "appear" to be working again a 5v supply when it is in fact a 12v supply... Ohh bugger...

I think there's a possibility I may be an idiot... ;) and I think I figured out my problem... More testing in a moment... ;)

Well, I've currently got it running on a 2.7% duty cycle and I'm managing to push 19.9mA...

The first problem... The one that makes me an idiot... If you look at the schematic, notice where I put my current limiting resistors? On the ground side... ARG! Needless to say that was a good portion of my problem... (resistor was in series with B-E junction...)

The next problem after getting a good solid pulse at 10v (2v drop because of LED) was that I still wasn't pushing what I thought I should be... I noticed a real sharp transient on the rising edge... Spikes upward of 40+ volts for about 300ns... I'm not sure what effect this may or may not have on my issue, but I suspect it has something to do with it... Anyway, by swapping out the 2222 for a mosfet (7000) I managed to be able to drive it at about 19.9mA...

I also considered "catching" and utilizing that spike, I added a cap across the supply down to the base of the transistor (still on 2222 then)... That actually worked great, but I'll have to look into it more to see if I could get away with only doing the row drivers... Can't do the column drivers or I'll end up with columns "slightly" responding to row data that isn't their own...

So, bottom line is, more testing to be done, but I'm certainly getting closer...

Well, as they say, "One step forward, two steps back"...

As part of my testing the other day, I had removed both transistors/FETs and was working only with one...

Today I added in the other driver and I'm pretty much right back where I started...

I realized what a buffoon I was when I drew up that schematic... I had NPN transistors on both rows and columns... That works, but it also means whichever transistor has the load on the emitter side is going to turn on a bit later than the first... The first has to be on before it can... Although this should happen very fast, in dealing with the speeds we're going, I'm guessing it's clipping a lot of the time out...

So... I didn't have any plain P-FETs, but I did have some J-FETs (P-channel)... I just reversed my code a bit and put that on the supply side...

Now in theory both fets should be able to turn on independantly of what the other is doing... So this should put me back to a good working state...

Unfortunately that didn't happen... I'm back down to like .8mA now... The only thing I can figure is even though I'm setting the PORTC register in one command, it must be doing them independantly? Causing a slight time difference? I wouldn't think it would be enough to affect it that much, but I dunno... I'm gonna get the other channel of the scope fired up and look at both bases and see what if any time difference exists between the two... I also need to check the specs on this J-FET.. I'm sure it's logic level since that's generally all I keep around, but I don't know for sure, so I'll have to make sure it's not too slow...

Just a quickie - thanks for documenting all your findings. I'm actually enjoying reading the story unfold. Whilst a lot of this is above me, I'm learning slowly.

Keep it up.

Thanks, thats exactly why I figured it would be a good idea to do... A diary of sorts of the entire project from start to finish... Not only will it be fun, but hopefully it'll come in handy for others... If nothing else maybe some parts of it can play the part of, "Ohh, he tried that and it didn't work... No need for me to waste my time!" LOL...

Unfortunately I've been wrapped up and haven't had a chance to get any more testing done... I'm now finally sitting down but I'm staring at a stack of bills about the height of my laptop... LOL... If I can manage to get them done fairly quickly, I hope to give this thing a bit more thought/testing... ;)

Well, sorry I haven't had many updates lately... My time was completely consumed by changing the timing belt in my car...

Anyway, I finally had a few minutes to sit down and think about this with a clear head... I think my problem is trying to drive that much current with the transistors/fets that I have is just dropping the gain way too low... I'm going to give it a whirl to see what happens, but I think I'm gonna end up having to run darlington pairs. Which of course means doubling my number of transistors to 90 from 45... I'll have to check prices, but I'm guessing I can probably buy darlington pair transistors cheaper than I can put them together myself...

Once I get some testing done I'll post up the results...

Alright, sorry it's been a while, but between getting some things done that needed my attention, and a vacation, I haven't had much time nor been home much to give this any attention...

So anyway, here's an update... I only got a few minutes to fiddle around last night, so I need to do some more testing and such, but right now I have two ideas that are brewing...

While I initially wanted to minimize the amount of pins used to drive the display, I've come to realize that my initial thoughts just might not be achievable... So since I didn't actually spec how many pins I was going to use, the two solutions I've come up with are a bit of a compromise in that area....

So... Method 1: I "switch" my idea of using the 4017s to drive the rows and instead drive the columns, but divide them up a bit... In other words, for simplicity change the sign from 40 columns down to 39 and then divide those 39 columns by 3, and drive each of those rows seperately... In other words, even though only 5 rows will be "seen", physically there will be 15 rows... The first 5 rows driving the first 13 columns, the second 5 driving the second 13, and the last 5 driving the last 13... Each of the columns would be driven off the MCU while the rows would be driven via the 4017s (two cascaded)... Now what this does is pretty simple... Instead of a maximum of 5 LEDs on at any one time, I can now have a maximum of 13 LEDs on... I've also increased my duty cycle from 1/40 or about 2.5% up to 1/15th or 6.6%... This means that I don't need to drive each LED with nearly as much current as I had to previously...

Method 2: Is what I mentioned before about a variation of charliplexing... Actually it was this idea that came first, and the idea above was spawned off of this... Here's the thing... I need to go over everything a little closer, but with my initial thoughts, I THINK if I rig these things up right I'll be able to drive up to 42 columns (2 more than originally intended) directly off the chip with only 15 pins off the MCU... That's 2 less pins than the nerdkit version yet 18 more columns than that version... All that and I'll still have a 1/15th duty cycle... I believe the nerdkit version was running a 1/24th duty cycle and managed good brightness levels, so 1/15th shouldn't be a problem even with no drivers...

So here's the scoop... The first method is going to require 14 pins to drive 39 columns... Not to mention additional 15 FETs for each row (I doubt the 4017 will drive the LEDs direct, if I recall they can source/sink almost nothing). Plus I've still got the addition of 2 4017s...

On the other hand the second method is going to require an additional pin, (15 total) but will be able to drive 42 columns with the same duty cycle as above, and should not require ANY additional components at all, just the MCU...

Obviously the second method sounds like the way to go... I just need to do some testing to see if theory proves out since I seem to be running into a lot of cases lately where it doesn't! ;)

However, if testing comes out I think that's the way I'm gonna go... If not, then I'll look into method 1...

Just out of curiousity... If one of the "nerds" is reading this, have you measured the current on your sign? Can you tell me what current you were running to each LED via your method?

Whoops... Just went back and took a look at the nerdkit led project... I was thinking backwards... They actually have a 1/10th duty cycle... So I'll need to do some testing to see if 1/15th is gonna blow it... If so method 1 may need better looking into... ;)

Well, haven't had the time to spend with this that I'd like to due to attending a funeral... (never fun) but I did get a little time to test a bit...

The charlieplexing will work if I drive from the 12v, but not the 5v... That's an issue since it relies on the tristate abilities of the MCU... With the 5v I just don't get the brightness I want with a 1/15th duty cycle...

However, the other idea I had, of switching the 4017s around looks like it will work just fine... I was able to drive with way more current than I needed off the 12v... The big problem there is I smoked a few FETs in my testing because of the amount of current they were driving with 13 LEDs... Even with the 1/15th duty cycle it was just too damn much...

So I need to do more testing... I have a few possibilities... Go back to my quad 2as since they are in a TO-18 package that should sync away more heat... Stack the FETs up and run two or three per row to disapate across multiple ones... Use a bigger FET that can sync more current... Or last but not least cut the current back and run a bit less... (right now they were pumping about 21mA per LED, 13 LEDs per portion of the cycle.. or well above 250mA...) Still what I don't get is that with the duty cycle I should STILL only be pushing an equivilent of 18mA through the FET... So I duno... More testing needs to be done... I think I have a few more FETs that probably have excess smoke stored in them that need to be released... LOL