Dumb Led-Triks Display

[dirknerkle]

Don,

I read your PDF straight-through this past weekend and themes that kept repeating themselves were how frequently you had to borrow on your ingenuity and DIY skills to overcome an obstacle, how you evaluated the result and what you might have done/are planning to do differently the next time. In nearly each case, you reverted to (a) practicality, (b) cost-effectiveness and (c) immediate convenience. There was cause-and-effect methodology and success measurement included throughout, and all this points to a project that was extremely well conceived in-mind and implemented using a good road map. All in all, it was extremely well done, and (at least by me) very, very much appreciated.

I've had a somewhat similar idea in mind to use basic Vixen pixel mapping for the purpose of sending a text message to a "Dumb-Triks" board and I'll certainly use your manual as a template for documenting my progress. My idea involves creating a new Vixen plugin (of course) for converting a line of text into Vixen pixels and a modified version of Renard code at the board end to decode the designated channel information into the LED display. I think I can get it all done with a block of only 8-channels where one of the channels contains the appropriate control signals to accept the text message and then display it repeatedly until the next messsage is received or the message overwritten with blanks, which effectively deletes it. In my mind (what little there is of it) I see this using the standard Renard plugin for sending the data out to the controller and the remote Dumb-Triks board would be set to the appropriate start_address to grab the channel information.

So thanks in advance for giving me a little roadmap of my own to follow.

-dave

[djulien]

I've had a somewhat similar idea in mind to use basic Vixen pixel mapping for the purpose of sending a text message to a "Dumb-Triks" board and I'll certainly use your manual as a template for documenting my progress. My idea involves creating a new Vixen plugin (of course) for converting a line of text into Vixen pixels and a modified version of Renard code at the board end to decode the designated channel information into the LED display. I think I can get it all done with a block of only 8-channels where one of the channels contains the appropriate control signals to accept the text message and then display it repeatedly until the next messsage is received or the message overwritten with blanks, which effectively deletes it. In my mind (what little there is of it) I see this using the standard Renard plugin for sending the data out to the controller and the remote Dumb-Triks board would be set to the appropriate start_address to grab the channel information.

Sounds like a cool project! Is the Dumb-Triks a row/column matrix of LEDs, charlieplexed, or another type of structure?

Also, thank you for the comments about the article.

don

[dirknerkle]

Sounds like a cool project! Is the Dumb-Triks a row/column matrix of LEDs, charlieplexed, or another type of structure?

Also, thank you for the comments about the article.

don

I'm not really thinking about charlieplexing, but instead using an array of cheap 595 chips, one for each column of 7 LEDs x however many columns you want in your display. The PIC would store the data and continuously scroll the contents of its memory across the columns. The unused channel of the set of 8 channels would be used for sending various control codes to the PIC to tell it to load data or display data. To clear the display, you'd send blank cells, which would turn all the LEDs off but otherwise, it would continue to run until cleared, powered off, etc. I haven't chosen the PIC yet as I have to flush out a few thoughts first, but if you think of a character as a 5x7 display (35 bytes) there's enough room in a 16F688 to try the concept with up to about 32 columns of LEDs allowing about 6 scrolling characters on-screen at a time. Persistence of vision and the brain can assemble the words from there as the data scrolls across the columns.

My vision is actually to be able to "read" the text as if you had drawn it in pixels inside Vixen, so in a way, it would be self-documenting. The plug-in would select the channels to use (on an 8-channel boundary), you'd type the text into a text box and it would convert it into pixels which you could copy/paste wherever you wanted them in the sequence for the channels assigned to the board. And being that a song usually spans several minutes, there would/should be ample opportunity to display multiple messages.

Part of my goal is to create a very low-cost Triks effect doing something quite close to what you've done with the Dumb-RGB Grid, although not in a charlieplexed setting. I'm actually thinking that this whole concept could quite possibly be accomplished with a couple Olsen595 boards and a "driver" board similar to the Ren-C, which would extend the usefulness of the venerable old workhorse 595... :smile:

So I need to tame the bats flying around inside my head before jumping into this too far...

[djulien]

I'm actually thinking that this whole concept could quite possibly be accomplished with a couple Olsen595 boards and a "driver" board similar to the Ren-C, which would extend the usefulness of the venerable old workhorse 595... :smile:

Yes, it sounds like that would work.

Are you thinking of using monochrome or RGB LEDs? Even with just on/off control and no dimming, you could get the 7 basic colors with RGB LEDs. If the on/off control is at least ~ 60 Hz, then you could also get other colors.

don

[dirknerkle]

Yes, it sounds like that would work.

Are you thinking of using monochrome or RGB LEDs? Even with just on/off control and no dimming, you could get the 7 basic colors with RGB LEDs. If the on/off control is at least ~ 60 Hz, then you could also get other colors.

don

I'm really thinking of this as a truly dirt-cheap method to create a moving text display so monochrome is the original development mode. Being that one can buy 100 LEDs for peanuts, or even cut up a string of LEDs and use them instead, my goal is to make this a project for $20 or less.

[P. Short]

Don't forget that the max ground/vcc current for most (if not all) 74HC595 chips is 70 mA. This limits the per-output current to the somewhat low value of 8 mA. That is OK for driving the MOC3023 chips, but might not be enough for driving an LED to full brightness.

[dirknerkle]

Don't forget that the max ground/vcc current for most (if not all) 74HC595 chips is 70 mA. This limits the per-output current to the somewhat low value of 8 mA. That is OK for driving the MOC3023 chips, but might not be enough for driving an LED to full brightness.

That's an excellent point, thanks Phil. Current capabilities was one of the issues in the back of my mind (or front, wherever...there's a lot of empty space in my head where things rattle around...) I'm toying with using an actual stock Olsen595 including the ULN2803's which would solve most any current issue, or if I designed a board, possibly throwing in a transistor & resistor instead of the ULN2803A... I've got a bunch of 2N2222A's sitting in a box that seem to be calling my name, too...

Also, thanks for splitting this out into its own thread.

[tstraub]

Dirk, If you do go the 595 way would a Grinch also work? The Grinch used the same output plug-in as the Olsen 595. I have an old Grinch that somehow keeps working its way back to the top of one of my many boxes of misc parts and projects.

[dirknerkle]

Dirk, If you do go the 595 way would a Grinch also work? The Grinch used the same output plug-in as the Olsen 595. I have an old Grinch that somehow keeps working its way back to the top of one of my many boxes of misc parts and projects.

I don't see why not, other than the possible available current problem. I don't recall what the Allegro or MBI chips can provide...

[Matt_Edwards]

Sorry if this is adding more complexity than you want, but the TLC5916 is a "595 with 8x Constant current source built in" (my description) Would need to add the high side switches of the matrix.

[dirknerkle]

Thanks, Matt!

[tstraub]

If I am reading the MIB15027 datasheet (http://www.kingelectronics.com/images/products/MBI5027Datasheet-VA.02-English.pdf) correctly its good for 90ma/channel.

[ErnieHorning]

I’m right there with you. I’ve had several tubes of ‘595’s and a box of PN2222A’s sitting for a couple of years just waiting for something to do. I even have these in surface mount too, just in case you decide that we need to light up our shirts.

I like the simplicity of this also. I think the simple newbie type projects have been lacking for awhile. We need a few low level designs like this that beginners can understand.

I wonder if there’s a way that this can be done without the need for a PIC. I still think there are people that are lurkers because even programming a micro is a mystery.

[dirknerkle]

I’m right there with you. I’ve had several tubes of ‘595’s and a box of PN2222A’s sitting for a couple of years just waiting for something to do. I even have these in surface mount too, just in case you decide that we need to light up our shirts.

I like the simplicity of this also. I think the simple newbie type projects have been lacking for awhile. We need a few low level designs like this that beginners can understand.

I wonder if there’s a way that this can be done without the need for a PIC. I still think there are people that are lurkers because even programming a micro is a mystery.

You probably could do it just inside Vixen, but it'd be awfully painful to paint the pixels just right. I'm kind of leaning toward the 595 and a transistor instead of the ULN2803A, although I think for a test bench, a ready-to-run 595 ought to do the trick. I'm thinking of driving this whole thing using the stock Renard protocol and anybody using Renard ought to have a programmer. But pre-programmed PICs would be easy to do because it would be flashed with the display code, not the message. The message is buried inside the sequence in the pixels. I'm envisioning the code in my head (a VERY dangerous place for ANYTHING to be...) and thinking that implementing the output side first and the plugin later as the better way to go. It's not hard to envision the pixels in Vixen's screen -- if you set the column and row percentages so the pixels were square, just think of row 1 being blank except for control signals and rows 2-8 colored in to simulate letters. The plugin would take the text and color the pixels for you starting at a designated time or, you could just color them in manually if you like and make your own characters, smiley faces, whatever... Once you had your characters or words defined, you could just copy/paste them as needed. Any 8 channels could be used.

Oh well, more random thoughts.... but it's starting to gel (the idea, I hope... not my brain...)

[djulien]

I wonder if there’s a way that this can be done without the need for a PIC. I still think there are people that are lurkers because even programming a micro is a mystery.

If the lights are dumb LEDs and they are multiplexed, there would need to be something in there to cycle through all the rows. A free-running counter/decoder that enables the parallel outputs from shift registers could work, though. Then Vixen would just need to initially shift in the data.

don

[dirknerkle]

If the lights are dumb LEDs and they are multiplexed, there would need to be something in there to cycle through all the rows. A free-running counter/decoder that enables the parallel outputs from shift registers could work, though. Then Vixen would just need to initially shift in the data.

don

Yep, that's the general idea of what the PIC would do, along with "looking for" the start/stop characters that define the "load" operation. The "run" operation would start immediately after the load finished and repeat continuously so there's no need for a an unique "run" command.

[dlovely]

I would add a vote for the 595 and 2N2222's. I have a stock of over 100 595's and hundreds of MPS2222AG's I plan to use to drive my large clock. Would be interested in seeing where this goes. Maybe add a RTC for countdown/time? LOL. Once I get some work done on the clock I will start a thread with some info on it. Mostly just lots of test parts as of now. Currently using the SX28 but want to switch to a PIC when I have some free time.

[chelmuth]

I know you're idea is to me very inexpensive and I love that. But how easily adaptable could it be made to drive larger things. Like I'm thinking instead of just 5mm LED's a matrix of C9's I have about a bazillion around here.. Maybe eventually upgrade to LED Retro C9's. Currently my plan is that I have a large grid build out of 3 Renard 24SS's. 8x9 and I have the channels organized so I can read what I'm writing as far as sequencing and I just scroll if over one channel at a time and make the words.. See attachments.. Scrolling words is fairly easy but having a "frame" maker / matrix addin would make creating images much easier..

[dirknerkle]

I know you're idea is to me very inexpensive and I love that. But how easily adaptable could it be made to drive larger things. Like I'm thinking instead of just 5mm LED's a matrix of C9's I have about a bazillion around here.. Maybe eventually upgrade to LED Retro C9's. Currently my plan is that I have a large grid build out of 3 Renard 24SS's. 8x9 and I have the channels organized so I can read what I'm writing as far as sequencing and I just scroll if over one channel at a time and make the words.. See attachments.. Scrolling words is fairly easy but having a "frame" maker / matrix addin would make creating images much easier..

A 595 chip with a transistor (or a 595 with a ULN2803A + support power) can easily drive an SSR, which could then control multiple 1000 watt spotlights if you had enough power to make all that happen. So the idea can be expanded into something large enough where you'd need a stadium-sized venue for your display. The practicality in driving smaller LEDs is total available current consumption, money and, of course, available space. I see the limitation only in terms of $$$ and vision.

As far as Vixen goes, remember that all a colored pixel on the screen does is turn on a light. If you color-in multiple pixels on the same line, it turns that light on and keeps it on until the pixels are no longer colored in. If you organize your channels into vertical columns of lights, you could accomplish the same thing with almost any controller. It would take a while to do because it would be hard to envision it in the Vixen screen, but it's certainly doable now. My plan is a variant in that it essentially uses only seven of a block of eight channels of those pixels as the "programming" for a moving message display and uses the eighth channel as the "load" and "run" button. This allows for a common, 5x7 pixel arrangement that is more-or-less the minimum required to outline letters, not unlike how a cheap dot-matrix printer formulates dots into letters on paper. So this concept is really a bare-bones idea, with not a lot of high-def in mind.

The concept could be expanded to a higher-def venue -- it's exactly what mrpackethead is currently doing with his wonderful pixel displays. So the availability of high-def display is already there and, unfortunately, the scope of high-def and more channels invariably means more $$$. I will leave the expanding of this idea to others since one of the major goals of this whole project is a 5-letter word: CHEAP. As Ernie Horning mentioned earlier in this thread, this is kind of a low-end, low-tech, low-cost project that could (should) be easily built by most anyone and a way to implement a moving message display for very little money. It will also (hopefully) be an understandable and meaningful project for beginners that requires few parts that also provides some soldering/electronics building experience, which can build confidence and skill for other, more complex projects.

There are plenty of opportunities to get into sophisticated DIY displays; this project is looking in the other direction because often, simpler can actually be better. :smile:

[P. Short]

You may want to consider using a PIC16F627A (or one of its siblings) instead of the PIC16F688. It is capable of driving eight LEDs at the 25mA level by itself without external transistors. Both parts are capable of driving eight MOC3023-based SSR channels by themselves as well. The PIC16F627A is perhaps two bits more expensive, comes in an 18-pin package, and would require a fairly trivial port of the Renard firmware.

Oops, never mind, this is slightly off-topic. I was distracted...

[P. Short]

There may be a way to do this without using any micro at all. What I'm thinking of is the FT245 USB chip. You would be somewhat limited, of course, by the USB distance restrictions.

[Penfold]

There may be a way around the USB distance restriction to an extent. Although it would be fairly expensive and may or may not work. You would have to buy up to five USB 2.0 Extension cables with signal booster, and you could only get it 25 meters (roughly 82 Feet) max according to specs.

http://bestofferbuy.com/BAFO-USB-2.0-Extension-Cable-with-Data-Signal-Power-Amplifier-%285-Meter%29-p-26135.html?currency=USD

This is probably not practical, but I did find it interesting.

[ErnieHorning]

There may be a way to do this without using any micro at all. What I'm thinking of is the FT245 USB chip. You would be somewhat limited, of course, by the USB distance restrictions.150 feet far enough? http://www.pickegg.com/wholesale/45m-150ft-usb-over-rj45-usb-cable-extension-wire-adapter-blue.html?welcome=254

[dirknerkle]

You may want to consider using a PIC16F627A (or one of its siblings) instead of the PIC16F688. It is capable of driving eight LEDs at the 25mA level by itself without external transistors. Both parts are capable of driving eight MOC3023-based SSR channels by themselves as well. The PIC16F627A is perhaps two bits more expensive, comes in an 18-pin package, and would require a fairly trivial port of the Renard firmware.

Oops, never mind, this is slightly off-topic. I was distracted...

Thanks, Phil -- not off-topic at all! I've thought about that because the 16F627A is on the Ren-C as I remember, and it drives the 595 or Grinch directly and (probably) has a lot of the shift register/control signals already worked out, right? (I think your name is there in the ASM code anyway...:smile:) AND.... I just happen to have checked my stash of parts last night and lo' and behold, there seem to be a dozen of those pics right there... :grin: along with its sibling, the 16F628A! "Well," I thought to myself, "isn't THAT convenient!" Hmmmmm... lots of options here!!!

(I suspect our Arduino and Propeller supporters are already looking down their noses as this paltry project, but we PIC users are a stalwart and loyal crowd! :mrgreen:)

I'm not sure the FT245 chip would work -- for one reason, part of my goal is to keep this Renard-compatible so it could also be operated wirelessly, and while I haven't looked at the chip yet, I suspect that might require making the display in real-time. The idea I have in mind is to allow the pic to "load" X bytes of information based on the channel data and then continuously display it until the data is replaced, which is a bit different than real-time display. But I'm open to all kinds of ideas as this project starts to get a better focus! Thanks again.

-dave

[dlovely]

AND.... I just happen to have checked my stash of parts last night and lo' and behold, there seem to be a dozen of those pics right there... :grin: along with its sibling, the 16F628A! "Well," I thought to myself, "isn't THAT convenient!" Hmmmmm... lots of options here!!!

Dave, would you quit looking through my parts... LOL, I started with a few 16F627A before I moved to the SX52 for an easy prototype. Was having troubles with interfacing the RTC using the 16F627A. Seems our projects have taken us along the same paths in the past.

Dave

[P. Short]

Thanks, Phil -- not off-topic at all! I've thought about that because the 16F627A is on the Ren-C as I remember, and it drives the 595 or Grinch directly and (probably) has a lot of the shift register/control signals already worked out, right? (I think your name is there in the ASM code anyway...:smile:) AND.... I just happen to have checked my stash of parts last night and lo' and behold, there seem to be a dozen of those pics right there... :grin: along with its sibling, the 16F628A! "Well," I thought to myself, "isn't THAT convenient!" Hmmmmm... lots of options here!!!

It was irrelevant because your idea is to use 595 chips to drive the LEDs, not a micro.


(I suspect our Arduino and Propeller supporters are already looking down their noses as this paltry project, but we PIC users are a stalwart and loyal crowd! :mrgreen:)

I'm not sure the FT245 chip would work -- for one reason, part of my goal is to keep this Renard-compatible so it could also be operated wirelessly, and while I haven't looked at the chip yet, I suspect that might require making the display in real-time. The idea I have in mind is to allow the pick to "load" X bytes of information based on the channel data and then continuously display it until the data is replaced, which is a bit different than real-time display. But I'm open to all kinds of ideas as this project starts to get a better focus! Thanks again.

-dave

If operating wireless is a requirement, then I'm afraid that some sort of micro is necessary. The logic here is that wireless implies serial, and I don't know of any discrete UARTs or USARTs that are easy to obtain these days.

Perhaps it would be best to use a PICAXE chip, since afaik you don't need anything beyond a cable to program them. Despite their expense, I think that a PICAXE might be the easiest thing for a newby to use (at least, I hope that the built-in UART is available for general use).

[dirknerkle]

It was irrelevant because your idea is to use 595 chips to drive the LEDs, not a micro.


If operating wireless is a requirement, then I'm afraid that some sort of micro is necessary. The logic here is that wireless implies serial, and I don't know of any discrete UARTs or USARTs that are easy to obtain these days.

Perhaps it would be best to use a PICAXE chip, since afaik you don't need anything beyond a cable to program them. Despite their expense, I think that a PICAXE might be the easiest thing for a newby to use (at least, I hope that the built-in UART is available for general use).

Thanks for the PICAXE idea, too!

And wireless isn't a specific requirement in this case, but compatibility with Renard is because wired or wireless, I want to use an existing transmission protocol for simplicity. That way, a person who had a single SS24, for example, could simply add 8 more channels to his profile, use channels 25-32 for the dumb-triks message and daisy-chain it off the SS24. Since he'd be using Renard, there's a good likelihood he'd have a PIC programmer available (or in this case, a pre-programmed PIC with start_addr 0 would work fine). Or if he wanted wireless, he'd use start_addr 3 and it'd work the same way.

If he didn't have renard but used the parallel or 595 output (which a newbie may do), he'd do roughly the same but he'd add the Renard plugin and set the appropriate channels/port for it and do it that way. I think that's still "newbie-ish" of a way to make it work, eliminates the need to write a new output plugin, and maintains compatibility with existing equipment, but I've been off my rocker before and I may be again! :lol:

[dirknerkle]

It was irrelevant because your idea is to use 595 chips to drive the LEDs, not a micro.


I still need a driver board, similar to a Ren-C to read, decode, store and repeatedly send the data to the 595 chips to display the message, so the 16F627A is still a good idea for the driver board.

[chelmuth]

I have an idea and I'm wondering if this is maybe something like you're contemplating. Say I have 8 channels dedicated to the Dumb Triks.. I have timing broken down in to what ever ms I want, say 50ms. turning on channel 1 for to start the Dumb triks recording items to display. Then Use channels 2-x for programming in binary. ie. 0001 = a, 0010 = b, 0011 = c, 0100 = d, 0101 = e, etc. Each channel would represent one of the bits. Each 50ms time frame would be equal to one character. Then when done recording all characters turn off channel 1.. then the dumb triks starts to repeat recorded display..

[P. Short]

Were you thinking of placing the character generator in the PIC, or keeping in the Vixen plugin?

[chelmuth]

I think my idea the "font table" would be stored in the modified PIC code. I'm very new to all of this. So I'm not even sure it's at all possible. It was just an idea of how to get many out of a few. This was my idea of how to record the text as Dirk was talking about..

[dirknerkle]

I think my idea the "font table" would be stored in the modified PIC code. I'm very new to all of this. So I'm not even sure it's at all possible. It was just an idea of how to get many out of a few. This was my idea of how to record the text as Dirk was talking about..

That could work, too -- (stream of consiousness thinking here...) so if you sent a 41 (decimal 65, for the letter A) to the pic, it could print the letter A. That's an okay idea, but IMO it would be tedious to set exact values into multiple Vixen cells like that, and I'd be impossible to read on the Vixen screen. I'm also not sure how exactly those values are stored, recalled, recalculated, and transmitted in real time and then decoded at the PIC when the Renard protocol is asynchronous... there's no error-checking/redundancy going on to ensure that the character transmitted was the character received, and the message could easily become garbled.

That's why the concept I'm working on it essentially binary -- a cell is either on or off (value <=127 or >127) so there's a lot more leeway for evaluating a pixel's value which I would think for an asynchronous protocol would make the transmission/reception/decoding process more secure and predictable.

I may be talkin' through my hat on this whole concept, but in my feeble pea-brain, it seems like it ought to work. I like your idea of flashing the pic with the footprint for the letters because it makes good sense. I just think it requires a more exact communication environment that we have for blinky-flashy.

[chelmuth]

I was thinking it could be configured roughly as follows and the attached picture is what "Hello World!" would look like in Vixen.. Obvisouly other characters would need to be programmed like "." etc. I'm not sure of the memory capabilities of the PICs as far as font tables. Just throwing ideas at the wall. You were talking originally about an Add-in anyway so I was thinking readability in Vixen wasn't super important. Just have to make sure you get the 8 channels sent to the right pic. otherwise it would look weird when your arches started blinking morse code. LOL. There's another way you could program the pics.. Via Morse Code.. Only need one channel.. CQCQ DE Dirk . Display Hello World! Stop. LOL



BIT|CH|0123456789abcdefghijklmnopqrstuvwxyzABCDEFG HIJKLMNOPQRSTUVWXYZ!(Space)
---|-------------------------------------------------------------------------
1 |D1|1010101010101010101010101010101010101010101010 10101010101010101 1
2 |D2|0110011001100110011001100110011001100110011001 10011001100110011 1
4 |D3|0001111000011110000111100001111000011110000111 10000111100001111 1
8 |D4|0000000111111110000000011111111000000001111111 10000000011111111 1
16 |D5|0000000000000001111111111111111000000000000000 01111111111111111 1
32 |D6|0000000000000000000000000000000111111111111111 11111111111111111 1
64 |D7|0000000000000000000000000000000000000000000000 00000000000000000 1
9867

[dirknerkle]

I was thinking it could be configured roughly as follows and the attached picture is what "Hello World!" would look like in Vixen.. Obvisouly other characters would need to be programmed like "." etc. I'm not sure of the memory capabilities of the PICs as far as font tables. Just throwing ideas at the wall. You were talking originally about an Add-in anyway so I was thinking readability in Vixen wasn't super important. Just have to make sure you get the 8 channels sent to the right pic. otherwise it would look weird when your arches started blinking morse code. LOL. There's another way you could program the pics.. Via Morse Code.. Only need one channel.. CQCQ DE Dirk . Display Hello World! Stop. LOL


I like your idea... although the vision of my plugin would be that you'd type the text into it and it would paint the pixels on the screen for you -- WYWISYG. When the display ran, it'd look like this out on the TRIKS, and the only difference inside Vixen would be that the background colors would be white:

[P. Short]

There should be plenty of room in the PICs under discussion for a font table. Figuring 8 bits per column, 5 columns per character, and 96 characters, it would require 480 locations. The PIC16F688 has room for 2048 instructions and the PIC16F627A has 1024 instructions. The current Renard firmware is around 250-300 instructions, so there would be plenty of room for a 5x7 font table with 96 characters.

[chelmuth]

Ok I can see that. So basically you set the control channel on and then stream how ever many columns into the PIC then set the control channel off and it repeats streamed data either scrolling or something.. until control channel is triggered again.

[dirknerkle]

Ok I can see that. So basically you set the control channel on and then stream how ever many columns into the PIC then set the control channel off and it repeats streamed data either scrolling or something.. until control channel is triggered again.

Yep, that's essentially it. It's a very simple concept, and with a 595 chip for each column of 7 LEDs (ch 1 unused) it should be pretty easy to scroll them across the screen using the shift register design of the chips themselves. Only need one PIC to pump out the channels to the first 595 and from there, it's just simple replication for the number of columns in the display, which would be a flashed value in the PIC's firmware. Since there's no font profile and it just mimics the pixel in Vixen, one could draw very simple graphics or use it free-hand, coloring-in pixels at random. It's WYSIWYG. Designing the display and firmware first, I can leave the plug-in for later development and get this working right away. Then if I don't finish the plugin for the coming season, people can still get the job done manually. I could even provide a sample vixen sequence that had words and numbers pre-defined and one could just copy/paste them into a sequence as needed... a REAL lazy-man's way to the solution of programming the display... (and cheap, plus it'd be software version independent, too!)

A 16F688 has 256 bytes of memory and plenty of programming space for this so it could easily handle a display that was 50-100 columns at one byte/column, and at 5 columns + a space between each letter, a 96-column display could display 16 letters (672 LEDs). But I'm thinking that only about 36 columns and letting the viewer's brain and persistence of vision assemble the moving display of 6 viewable characters should work pretty well. The column limitation is the number of 595 chips that can logically be connected to the clock/latch signals, and I don't know what that is yet... The other limitation is power for the LEDs, which isn't rocket science... (well, maybe it IS rocket science, but we'll leave NASA to figure out its own problems...)

We're talking DUMB triks here... and DUMB is a word I can relate to (and do nearly every day of my life...:lol:) But this should give you a pretty good outline of how this thing would work...

Phil, I know you're watching this thread, any insight into the number of 595 chips I can hang on the same clock/latch signal?

[P. Short]

The limits due to DC loading are probably might higher than any practical number, perhaps up in the hundreds. The AC loading (i.e. capacitive and transmission line effects) are another factor, but I don't really know what that would be (this would also depend on the amount of trace/wire between the 595 chips). This AC limit is a function of the rise and fall times of the signals coming out of the PIC and not the clock rate. The limit can be calculated, but it has been so long since I've done so that I'm not prepared to do this now.

Just as a starting point, I estimate that the fall and rise time of the PIC outputs would be around 10 ns, or so, with load. If you have 36 595 chips out there, the physical length of the line would be perhaps 36 inches. The propagation delay (round trip) over this line is about 12 ns (perhaps a bit longer). This propagation time is long enough (compared to the signal rise/fall times) that I would be concerned about ringing, false triggering, etc., so it would be worthwhile to look into this further.

[budude]

bump

Uhhhhh.... what's the dealio with all the bumps?

[tstraub]

Uhhhhh.... what's the dealio with all the bumps?
I think he is trying to move the spammer off the top page. Of course a moderator will come and get rid of the spam if we just wait

[budude]

all figured out - just use the "Report Post" button next time...

[ErnieHorning]

bumpYou could just mention what an assume guy that budude is. It would still waste a post and accomplish the same thing as a bump but it wouldn't seem nearly as useless.

[ctmal]

I'm not 100% sure if I'm understanding what you're thinking correctly but if I am I think you might be able to get away without the control channel. If you're thinking that there would be 1 vixen channel per led sign column(can be 8 leds) then I'm on track, otherwise this might not be too helpful.
Anyway if your planning on allowing additional Renard devices to be added in line with the led sign, any time there is a change on any of those channels Vixen will send the complete channel value list on the data line so you would have to handle that. I'm assuming with a control channel you could just discard the information but if you handled the data each time it was sent and latch it when you've received all the data for the sign you wouldn't need the control channel. This is also assuming all the control channel does is tell it when to latch the data.
Also, I've had better luck in a past project double buffering the display. This way you don't need to turn off the display while receiving the data, just switch to the new display data when it is ready.
Not sure if I'm on the same page but I do like your idea how to have Vixen control the sign...I wish I thought of it(maybe I wouldn't have abandoned that past project).

[dirknerkle]

I'm not 100% sure if I'm understanding what you're thinking correctly...


LOL!!! That's what nearly everybody tells me as the blinky-flashy season gets closer!!!

Chris, you've been tremendously helpful in providing ideas, considerations, cautions, suggestions and enthusiasm -- I appreciate them all very much! Phil, you too -- you look at goofy projects like this from a completely different viewpoint that is not only germane, but powerfully shaping. Thanks to you, too!! DIYC truly is a great place for idea-sharing -- I'm constantly amazed at the creativity shown by so many, many people.

And now.... back to our story...

Actually, dumb triks is not going to be a pass-data-through kind of board -- it's not that smart! (hah!) Yes, the plan is to use the Renard protocol, but this would be an END device or, it could be set with a start_address if it's set up wirelessly. Nothing will daisy-chain off of it. I suppose I could put in a parallel RJ45 connector to make it passive and simply pass the same signal through that came in; then the receiving controller from it could use start_address firmware to skip the 8 channels the dumb triks board would use. So that's a workaround anyway... But by using the Renard method for data transfer, I won't have to write a a special output plugin for Vixen, there are fewer things to configure, and my end-goal is to make life simpler for the user while still providing a workable, affordable and easy to build message display. Making it an end device and not passing unused channel information to the next controller also tidies-up some timing issues that may occur down the road.

I'm etching a few prototype boards this afternoon to test concept, electronics and the firmware (that I have yet to code), but a 4-column display is all I'll need for basic testing and proof of concept. From there, it should be simple to etch a few more and see what happens when it expands in size to display more characters.

Double-buffering is a really good idea but I think when I get to coding, I'll work on basics first and add whatever bells and whistles I can later...

[caviar]

I think that name need to changed to Cheap Trick. If I tell my wife I am going to go work on my dumb trick, I will have to listen to (how much did you spend on that dumb stuff), but if we called it "cheap trick" it may save me some headache. Maybe, we should rename everything with "cheap" in front of the name, or like the( $2.00 renard 64 and $.10 ssr). lol

[budude]

That and "working on your trick" could take on completely different connotations! ;)

[ErnieHorning]

I don't think you can exactly call anything with a micro, 'dumb'.

[dirknerkle]

I thought about giving it a proper name but telling Mrs. Dirk, "Dear, I'm going down to the shop to work on Larry" didn't quite have the right ring to it...

I'm open for any suggestions though.... "Cheap Triks" is good, "Triks, it's not just for breakfast anymore" is too long, "Whazzup, Trix?" is too street-savvy....

[dmcole]

"Cheap Triks" is good

+1 ...

\dmc

[chelmuth]

I Vote for "Vicks" being that it will be a Vixen Controlled Triks :)

[dirknerkle]

I Vote for "Vicks" being that it will be a Vixen Controlled Triks :)

Excellent idea. How about VixTriks?

[chelmuth]

I'm ok with that.. Let's get it to work now.. lol.. I need to get to ordering some things so I can play and get to understanding how all these micros work better.

[dirknerkle]

I'd agree -- now it has to work! I've built the test circuitry, it's ready to go, now all I have to do is start coding firmware.

Onward....

[ErnieHorning]

So 'Dirknerkle's Ultamate Magic Box' probably wouldn't work? :p

[dirknerkle]

So 'Dirknerkle's Ultamate Magic Box' probably wouldn't work? :p

Holy cow! Ernie, you've had too much birthday cake today!!! :lol:

[IdunBenhad]

Hi:
How about "trikyvixy"?

Sounds like a con-woman of the night.

[djulien]

How about "trikyvixy"?

Sounds like a con-woman of the night.

I had a hard enough time convincing my wife that "Vixen" was computer software. She's going to cut off my internet access and close my PayPal account if I try to build something with that name! ;)

don

[P. Short]

Am I still understanding this correctly? What you are discussing is an 8xn dot non-multiplexed, non-dimmed matrix. Each column of the matrix would be driven by a 74HC595 plus buffer transistors, with the 595 chips daisy-chained. There is a PIC of some flavor (PIC16F688, perhaps) translating the Renard protocol into the signals needed to control the 595 chips. The data sent from the PC to the PIC is basically a bit-map, with the 5x7 font-generator residing in the PC.

[dirknerkle]

Am I still understanding this correctly? What you are discussing is an 8xn dot non-multiplexed, non-dimmed matrix. Each column of the matrix would be driven by a 74HC595 plus buffer transistors, with the 595 chips daisy-chained. There is a PIC of some flavor (PIC16F688, perhaps) translating the Renard protocol into the signals needed to control the 595 chips. The data sent from the PC to the PIC is basically a bit-map, with the 5x7 font-generator residing in the PC.

Yes. Dimming is not a concern; LEDs are either "ON" or "OFF."

The character is a standard 5x7 "dot matrix" character. The best way to understand it is to think of a sequence that has only 8 channels and is set to use the standard Renard-modified plugin for communication to the controller.

Row 1 (channel 1) is the control channel, where two consecutive cells of values > 7F would signal the beginning of reading data, and terminating with the same characters for simplicity.

Rows 2-8 contain the character itself in WYSIWYG, although each of the 5 columns that make up the character is essentially a "binary" number (cells either ON or OFF). The channels would be read by the PIC one full column at a time and translated into a HEX number for storing in EEPROM (in FIFO order). In this way, the PIC could easily store 180 columns (bytes) which would be roughly equivalent to a 30-character message including a spacer column between characters. Upon receiving the second pair of consecutive 7F cells in channel 1, the PIC would stop "loading" data and would begin displaying it, over and over until the next time it receives the control codes to load a new message. This allows it to be "loaded" and run automatically if that was desired. Channel 2 is at the "top" of the LED display; channel 8 would be at the "bottom."

During play, the PIC would read the values from memory and reform them into "binary" and send them to the 595 chips with proper latching. I'm planning to use one PIC pin for the serial data output and another PIC pin for the latch signal. The clock signal would be provided by the same crystal that also clocks the PIC.

I'm fairly sure the 16F688 has the horsepower to do this, and it has enough EEPROM too. However, I'm not sure whether the timing would work if this were put into a daisy chain environment where sending serial data downstream to other Renard controllers at 57600 is feasible. Therefore, I see this as an end-device, using the start_address function to allow it to decode the desired 8 channels out of the total stream of data. Because daisy-chaining the data is not a concern, I think that a display could easily be 30 columns wide and would display up to 5 scrolling characters simultaneously. The viewer's brain can assemble it from there into words. Such a display would require only 210 LEDs, thirty 595 chips, and either 30 ULN2803As or 210 transistors and only one controller. I think that total cost could be as <$50 if pegboard, perfboard and direct wiring was used so while it's not dirt cheap, it's pretty affordable, would be easy to program and afford the user with a way to change the message multiple times during the same song and also SEE what the message is on-screen. It would also allow for manual, free-form creation of other letters or simple graphics by simply coloring in two pixels in channel 1 as the control, coloring in various pixels in channels 2-8 as you wanted, and finished off with a pair of channel 1 pixels again. At 180 columns' worth of data (1 byte/column), if you were sequencing at 50ms intervals, your message could take up up as much as 9 horizontal seconds of time on the screen.

I've started looking at the Renard start_address ASM code and while I haven't started editing anything yet, I'm just working up an understanding of what's happening where, and where the code would logically be inserted in place of the code that's there now.

So there you have it. All the beans spilled...

[ErnieHorning]

Not to toss the proverbial wrench in here but how you are compensating for the fact that Vixen doesn’t send out data if nothing changes?

[P. Short]

OK, just making sure that I understood what was going on before adding my $.02 to the discussion.

Anyway, I was thinking of a different approach to accomplishing what you are trying to do. The essence of this is make it a multiplexed 8xn display, sort of like a smart mini-trix. Each of the eight rows of the display would be enabled by one output from the PIC, one row at a time. The columns would be driven by the outputs of a series of 74HC595 chips (the difference is that here each 595 output controls an entire column, rather than just one LED). This would greatly reduce the amount of hardware that is needed...basically by a factor of eight.

Since the micro would be doing the multiplexing (unlike LEDtriks), it would need enough memory to store the entire display map. The PIC16F627 chip has 224 bytes of memory, enough to handle about 32 characters of data (larger than most people would want, I think), although it could be made even larger by storing ASCII characters in the micro rather than the decoded bitmap.

Only one row would be enabled at a time, so the column drivers would only need to drive 25 mA each. This is more than the 595 chip can drive, but a simple 2N3904 or 2N3906 transistor would suffice for each column driver. The row drivers would need to be able to drive 25mA * N, where N is the number of columns. For this you would need something beefier, perhaps a TIP120 (or parallel MPSA24 or MPS2222 transistors for modularity).

Anyway, just a thought.

[djulien]

Not to toss the proverbial wrench in here but how you are compensating for the fact that Vixen doesn’t send out data if nothing changes?

In the plug-in, a timer could be used to resend the data if needed, or the PIC could just replay it if it is stored in RAM or EEPROM.

don

[IdunBenhad]

Hi"


CTMAL
I'm not 100% sure if I'm understanding what you're thinking correctly


Around here, things are explained differently than I understand them!

[dirknerkle]

Not to toss the proverbial wrench in here but how you are compensating for the fact that Vixen doesn’t send out data if nothing changes?

When you include the text in the designated pixels, you have data to send. The control code tells the PIC to "load" the data into memory and the second control code tells it there's no more data, and from then on, the pic doesn't need anything more -- it just keeps displaying the message until it gets another sequence of data. The idea is that the pic doesn't need a steady stream of information -- it only needs X number of bytes, which you'd put in the cells and which would be sent to the PIC.

[dirknerkle]

OK, just making sure that I understood what was going on before adding my $.02 to the discussion.

Anyway, I was thinking of a different approach to accomplishing what you are trying to do. The essence of this is make it a multiplexed 8xn display, sort of like a smart mini-trix. Each of the eight rows of the display would be enabled by one output from the PIC, one row at a time. The columns would be driven by the outputs of a series of 74HC595 chips (the difference is that here each 595 output controls an entire column, rather than just one LED). This would greatly reduce the amount of hardware that is needed...basically by a factor of eight.

Since the micro would be doing the multiplexing (unlike LEDtriks), it would need enough memory to store the entire display map. The PIC16F627 chip has 224 bytes of memory, enough to handle about 32 characters of data (larger than most people would want, I think), although it could be made even larger by storing ASCII characters in the micro rather than the decoded bitmap.

Only one row would be enabled at a time, so the column drivers would only need to drive 25 mA each. This is more than the 595 chip can drive, but a simple 2N3904 or 2N3906 transistor would suffice for each column driver. The row drivers would need to be able to drive 25mA * N, where N is the number of columns. For this you would need something beefier, perhaps a TIP120 (or parallel MPSA24 or MPS2222 transistors for modularity).

Anyway, just a thought.

Good thoughts, Phil -- thanks. I'm actually trying to get away from the multiplexing issue while at the same time, I'm trying to find another use for the good ol' Olsen 595. With this concept, you'd connect the outputs from two of the Olsen 595's RJ45s to one column and not use the 8th channel of each pair of outputs. Daisychaing 3 or 4 Olsen595's or Grinches into one another and you'd have all the display electronics right there, ready to go. All you'd need is the controller to gather the Renard data, decode it into the appropriate signals and feed it into the 595/Grinch. Bingo. Instant Triks display.

So a guy could dust off that old 595 or Grinch, glue some leds into some holes on a piece of pegboard, assemble an inexpensive Renard 8-channel controller (w/o triacs) and have a workable moving message display in a single day.

This may be a dog that won't hunt, but I have a sneaky suspicion that it may actually work.

[P. Short]

So it seems that you'll be using a standard Renard PCB as the controller (with the new firmware, obviously), rather than design a new board.

[dirknerkle]

So it seems that you'll be using a standard Renard PCB as the controller (with the new firmware, obviously), rather than design a new board.

Yes, you could say that I'm trying to make a concept that would take existing gear and use it in a slightly different way. Repurposing older equipment is perhaps better than letting it gather dust or throwing it out. Besides, who know how many stacks of 595 boards Macrosill may have sitting around waiting for people to buy? :lol:

However, I have made a sort of "half-595" board (sort of a 297.50 board?) and some LED boards that could suffice as a "kit" for those who don't have a 595 and want to build the display portion out yet not use pegboard, etc. Combine them with one of the MiniRen or WiRen boards I made a month ago and a person could certainly etch their own setup pretty cheaply.

[P. Short]

OK. The scheme that I proposed above could/would use any one of the existing 595/Grinch boards for the column drivers, without any disadvantage. What would take a new design would be the combined controller/row_driver board (basically the Ren-C board with seven or eight additional transistors).

What is the reason for being reluctant to use a multiplexing scheme?

[dirknerkle]

OK. The scheme that I proposed above could/would use any one of the existing 595/Grinch boards for the column drivers, without any disadvantage. What would take a new design would be the combined controller/row_driver board (basically the Ren-C board with seven or eight additional transistors).

What is the reason for being reluctant to use a multiplexing scheme?

I was thinking of this as a sort of "newbie" project and I envisioned the prospects of soldering a matrix as making it more complicated.

It's quite possible I'm not seeing the big picture of what multiplexing can accomplish here, as I'm thinking of a column of 7 LEDs as basically having a common anode (pin1 of an RJ45) going to a resistor network, and that branching out to the anode of each LED, with the cathode being switched by the ULN2803A (or transistor); the column could essentially be a standalone "stick" PCB (or pegboard) about an inch wide.

When the "sticks" are mounted adjacent to one another it could form a moving sign. However, if the sticks were separated and hung separately in a tree or elsewhere, it wouldn't be very hard to make them simulate dripping icicles instead. Soldering them into a matrix would make it much harder to separate them.

[P. Short]

In your scheme each 'stick' has eight wires going into it. On the 'stick' side of things one wire goes to the common pin of the resistor network that you mention, the other seven wires each go to one cathode. On the system side of things, one wire goes back to the +5V, the other seven wires each go back to the output of a 595 (through some sort of transistor).

In the matrix scheme each 'stick' is wired internally the same as in your first scheme. On the system side, the first wire goes to the output of a column driver (unique to that 'stick'), and the other seven wires each would go to one row driver (in common with the same wire from all of the other sticks). Not too much harder to wire up than the first scheme, imo.

[ErnieHorning]

I’m wondering, in the matrix scheme whether there would be enough time to use a ‘595 for row selection. This way, chaining ‘595’s vertically would allow you to expand in both directions.

[P. Short]

I’m wondering, in the matrix scheme whether there would be enough time to use a ‘595 for row selection. This way, chaining ‘595’s vertically would allow you to expand in both directions.

Yes, although I was trying to keep the duty cycle on the LEDs above 1:8. The duty cycle on LEDtriks is 1:16, so I suppose there is room for a little bit of vertical expansion.

[somtng4u2c]

And we can call this a (simple triks)

[chelmuth]

I was re-reading posts and caught something in Ernie's post about vixen not resending data when nothing changes.. As an example lets use the letter "C". Here's is a text version of what I believe to have understood how you plan this to work..

Channel one sends two 7F cells then off.. After this. Channel 2-8 sends all on.. next column channels 3-7 send off, but 2&8 don't send anything as they remain on.. Then after 4 columns go by channels 2&8 turn off, but 3-7 still off get no information. my question is how does the triks know how "wide" the letter is. How does the triks know that 5 columns went by and not 6-7. I'm just picturing something like.....



........ .... instead of ..... .....
. . . . . .
. ... . ....
. . . . . .
........ . . ..... . .


I'm just wondering if on the control channel there needs to be a "column beat" after the record start sequence..

[djulien]

Yes, although I was trying to keep the duty cycle on the LEDs above 1:8. The duty cycle on LEDtriks is 1:16, so I suppose there is room for a little bit of vertical expansion.

If the LEDs are arranged as columns (ie, the hardware can only turn on the LEDs in one column at a time) and you are displaying text chars, there will be a blank column between each char, and skipping the blank columns will let you get a better duty cycle. For example, if you are using a 5x7 font with 1 blank column between each char, then you only need to send out 5 of every 6 column addresses. If the first char was all the way to the left, you could send out the column addresses for the 1st, 2nd, 3rd, 4th, 5th columns (for the first char), skip the 6th, then send 7th, 8th, 9th, 10th, 11th (for the second char), etc. Which columns to skip will vary according to the scroll position, making the firmware a little more complicated, but it would give you a 17% improvement in duty cycle (1/5 rather than 1/6).

don

[ErnieHorning]

Which columns to skip will vary according to the scroll position ...Which brings up the issue of scrolling in which all spaces will need to be updated.

If a compare is always made with the previous column value, an update may be skipped. This may be impossible though with limited RAM.

[dirknerkle]

I did a little testing tonite and here's how I plan to implement all this stuff. I've read all the ideas -- thanks to everyone for input -- but I think we're overengineering this when the solution is actually pretty simple. It involves the use of the control channel, channel 1. I've attached a screen shot of various frames of data. Explanation:

The upper left shows the Vixen screen with "MERRY" in WYSIWYG. Note the two control characters in channel 1 at the very start and end of the text. The control characters have the value FF (a change from my original idea). Two characters are used for redundancy (in case one is accidentally missed somehow). The value of these characters is >200 (C8). To differentiate the start/end control characters from anything else in channel-1, no other characters in channel-1 would be greater than C8.

Two Notepad screens are visible; one over the bottom of the Vixen screen showing the rows of bytes Vixen sent out and the other to the right, where I've replicated the word MERRY by drawing over the FF values in the data. Note also the green box drawn around the data of the first channel. Notice that the value changes with each transmission interval. This is the secret to causing Vixen to transmit everything: the channel 1 value changes with every cell. I've simulated it here by adding a ramp up for the duration of the text, but the planned plug-in I have in mind would increment the value in each channel-1 cell by 2 up to 180 and then back down so that no two adjacent cells have the same value.

The far right box shows the XCTU terminal screen in which I've monitored the transmission from a Ren-W. It shows the data as the Renard controller would receive it. (This was the raw source of the data you see reformatted for easier reading in the Notepad screens.) XCTU is the software used to configure an XBee radio and I've found it wonderfully efficient for monitoring Vixen data.

**The problem with identifying control characters is solved by the value of the characters themselves as well as that they're only in control channel 1.

**The problem with Vixen not sending data every time is solved by putting a different value in each cell in the control channel so that no two adjacent cells have the same value.

Ought to be a piece of cake. :cool:

[chelmuth]

Well that answered my question as to how you were going to get vixen to resend all data.. That rampup is the "heartbeat or column beat" I was referring to ... I had just not heard any mention of it earlier.. I had read about start and end but nothing in the middle of the control channel and Ernie's statement caught my attention the second time around. That looks like a good fix to me..

LOL. I say fix like it was ever a problem for you.. You had it figured out all along.

[ErnieHorning]

Here’s a thought, suggestion, think out of the box or whatever you want to call it.

Since you’re already requiring two timing slots before and after the text, why not add the eighth channel back in and require that all eight channels must be filled in twice before and after the text. This will give you two start marks that can be used for timing the rest. If no data is sent during a time slot, it’s blank.

Since each channel can contain value of 1 to 255, the timing marks can also contain configuration data. You can still use channel 1 to contain configuration but since you have eight channels; each channel could have its own configuration. The reason I say this is, by design, it’s possible to have separate strings for each row. It does open up the possibility for other ideas.

The two start/end marks could be FF,>C8 or >C8,>C8 or >C8 and binary invert the second one as kind of a checksum.

You’re using a micro and you have a lot more power available, it seems a shame to waste a channel.

[djulien]

Which brings up the issue of scrolling in which all spaces will need to be updated.

If a compare is always made with the previous column value, an update may be skipped. This may be impossible though with limited RAM.

I misunderstood the refresh mechanism - I was thinking that unless a column was specifically addressed, it would remain dark.

Good point about the unchanged columns - that could save even more, although it would be more variable.

don

[dirknerkle]

I thought I'd put together a 5x7 font that I can use for testing this crazy idea, and it took only about 15 minutes to do the alphabet and digits. So I tried using copy/paste to make a couple typical sentences and 5 minutes later, I had a couple typical sentences done.

I'm wondering if I even need to bother writing a plugin for this -- it's brutally simple just to do it manually. I've attached a JPG of the screen and the sample VIX sequence and profile for the font...

[ctmal]

It seems to me that a separate plugin isn't needed. You would just need to make sure everyone knows what they need to do in the control channel.

This is a pretty cool project!

[dirknerkle]

It seems to me that a separate plugin isn't needed. You would just need to make sure everyone knows what they need to do in the control channel.

This is a pretty cool project!

Well, this is an attempt to get an awful lot done with a small budget and little muss and fuss... and writing documentation is cheap! All I need now is the PIC firmware and I'll start on that tomorrow. I think I'll include a firmware option to display the message in real-time instead of storing it, too...

[tweist]

Do you ever stop??????
Really nice idea. How big will you display character be in inches?

[DaveJZ]

Dirk.. any idea on what the cost of this project will end up being if one had to order all the parts?

How many 5x7 panels is suggested?

[dirknerkle]

Do you ever stop??????
Really nice idea. How big will you display character be in inches?

Hiya! All depends on how big you want to make it. Characters are 5w x 7h so if you put LEDs really close together, it'd be maybe 2" tall, but if you spread them out 1" apart the display would be 6" high. I've made a prototype based on 1" centers for testing that's 6 columns wide, enough for testing the concept and displaying one complete character plus a spacer column.


Dirk.. any idea on what the cost of this project will end up being if one had to order all the parts?

How many 5x7 panels is suggested?

Way too early to know what the cost will be, nor do I know how many columns or panels it will support. I'm currently working on firmware to test the darned thing. The prototype display I made (see above) has six 680-ohm x 8pin resistor networks and 42 red LEDs, so that can't cost more than $5 for the one character it can display, so I'm thinking 5 display panels (for 5 characters) would be around $25 in parts if you used red LEDs, which are probably the cheapest color to buy. I also made a couple Olsen595 driver boards for switching and power to drive the LEDs; together they make up a 64-channel Olsen595, so there are 8 each of 74HC595 and ULN2803A chips on those two boards; at 1 pair/column a single Olsen595 (or Grinch) would handle 8 columns in the display. In place of the ULN2803A you could use an inexpensive transistor such as a 2N2222a or 2N3904 and resistor for each output, but I found the 18-pin ULN2803A to be a lot less soldering and more compact than soldering 42 transistors and resistors. :grin:

I'd suggest not ordering any parts yet...

[P. Short]

You could use a smaller resistor to get more light output. Using a 5V p/s and normal 25 mA LEDs, you could use 150Ω networks. On the other hand, if all you have on hand are 680 Ohm resistors, use those.

Although I would agree with dirk's comments about not ordering parts now...

Edit...or even 120Ω, but no smaller.