Searching \ for 'LED Signboards' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/displays.htm?key=led
Search entire site for: 'LED Signboards'.

Truncated match.
PICList Thread
'LED Signboards'
1997\05\14@164137 by Mark G. Forbes

flavicon
face
>Date:    Tue, 13 May 1997 17:12:11 -0700
>From:    "Jann P. Kaminski" <spam_OUTJannTakeThisOuTspamUNIAX.COM>
>Subject: LED Signboard

>I am interested in making custom signboards out of LED modules (5x7)
>using PIC uC's. Signboards are those scrolling displays or marquees seen
>wherever advertisers want their message observed. Is there a schematic /
>program for this project? Useful features would be expandable character
>table, string length, panning, scrolling, ....  Any information would be
>helpful.
>J Kaminski

In a nutshell, you need more horsepower than you might think for projects
like this. These displays are typically scanned, and that imposes a lot of
overhead on your CPU to keep the display refreshed properly. If you don't
go fast enough, you get flickering. It's important to note that the flicker
can be acceptable if you're looking straight at it, but can be very annoying
if your eyes are moving around (as in our industry, where we make these
kinds of signs for use in casinos).

As the sign increases in size, you need to make some hard decisions regarding
the kinds of information you want to present. If you're only interested in
character data, then you can store font images and assemble a display screen
with fairly small amounts of storage. If you plan to display graphics, you'll
need more space. If you want animations, plan on *lots* of space, since you
won't have time to do any clever mathematical transformations in real time.
You'll need to just store every frame of the animation, then play them back
sequentially.

Most manufacturers use high-current drivers like the Allegro parts, which
combine a shift register and output drivers. You need to work out a column
and row scanning system that will refresh your display, and then send the
appropriate clock, enable, data and strobe signals to the driver chips. It's
not a trivial amount of work. We have several people devoted full-time to
display development.

After you've got all that stuff working right, then you can start worrying
about the higher-level issues of scrolling, flashing, blinking and the
types of information you'll present. Note that you may have to modify your
display refresh algorithm depending on the kind of motion or effects you're
trying to achieve.

They aren't cheap to build, either. LED modules go for $5-6 each in small-ish
quantities, and you can easily put several hundred dollars into the display
modules alone. Good luck with your project.


Mark G. Forbes, R & D Engineer  |  Acres Gaming, Inc.    (541) 766-2515
KC7LZD                          |  815 NW 9th Street     (541) 753-7524 fax
.....forbesmKILLspamspam@spam@peak.org                |  Corvallis, OR 97330
http://www.peak.org/~forbesm
mforbesspamKILLspamhq.acresgaming.com

"There has been an alarming increase in the number of things I know nothing
about."
---Anomalous

1997\05\14@200642 by John Payson

flavicon
face
> >I am interested in making custom signboards out of LED modules (5x7)
> >using PIC uC's. Signboards are those scrolling displays or marquees seen
> >wherever advertisers want their message observed. Is there a schematic /
> >program for this project? Useful features would be expandable character
> >table, string length, panning, scrolling, ....  Any information would be
> >helpful.
> >J Kaminski
>
> In a nutshell, you need more horsepower than you might think for projects
> like this. These displays are typically scanned, and that imposes a lot of
> overhead on your CPU to keep the display refreshed properly. If you don't
> go fast enough, you get flickering. It's important to note that the flicker
> can be acceptable if you're looking straight at it, but can be very annoying
> if your eyes are moving around (as in our industry, where we make these
> kinds of signs for use in casinos).

"That depends".  For scrolling text applications, a simple PIC may be
quite sufficient (even a 12C508 plus EEPROM for very small signs like the
42x5's that seem popular on fast food menus).  As for refresh rate, that
depends a lot upon whether you're displaying static or scrolling images.
For static images, the faster the better; for scrolling images, you want
to scroll an integer number of pixels per frame [typically one] unless
you're doing tricky fractional-dot techniques.

> As the sign increases in size, you need to make some hard decisions regarding
> the kinds of information you want to present. If you're only interested in
> character data, then you can store font images and assemble a display screen
> with fairly small amounts of storage. If you plan to display graphics, you'll
> need more space. If you want animations, plan on *lots* of space, since you
> won't have time to do any clever mathematical transformations in real time.
> You'll need to just store every frame of the animation, then play them back
> sequentially.

Here again, "that depends".  If your animation merely consists of sliding
sprites around, where each sprite has 2-4 frames, you can do the motion in
code with just the sprites in RAM/ROM.

> Most manufacturers use high-current drivers like the Allegro parts, which
> combine a shift register and output drivers. You need to work out a column
> and row scanning system that will refresh your display, and then send the
> appropriate clock, enable, data and strobe signals to the driver chips. It's
> not a trivial amount of work. We have several people devoted full-time to
> display development.

Need anyone to do some contract for you?  I've been itching to do one of
those things for years; at present all I have are small 5x28 and 7x40
units I wired myself [the 7x40 was a real pain... I shoulda spent the $100
or so and got a PCB].

> After you've got all that stuff working right, then you can start worrying
> about the higher-level issues of scrolling, flashing, blinking and the
> types of information you'll present. Note that you may have to modify your
> display refresh algorithm depending on the kind of motion or effects you're
> trying to achieve.

Your last point is extremely important, though I think you need to "worry"
about the higher level issues before you design the circuit.  For example,
unless you have a single scan which goes from one edge of the screen to
the other, you will need to watch out for "seams".  For example, if you
have a 15 dot high display which is wired as three groups of five scanned
rows, you will need to take special measures in your scanning if you wish
to avoid visible seams between these groups.

Also, you should consider the question of whether you want to use a bitmap
buffer to hold the current screen, or whether you wish to generate it
continuously from characters as you're scanning.  If you have a "large"
CPU [i.e. something with external RAM] this question is often a no-brainer
(just do it), but when trying to produce a minimal design, it can be a bit
more complicated.  For example, the easiest method of avoiding seams
requires that you approximately double your display buffer allocation if
you use a bitmap; if you're converting text-to-bits as you scan, then you
may not require the extra buffering but your algorithms will be more
complex.

> They aren't cheap to build, either. LED modules go for $5-6 each in small-ish
> quantities, and you can easily put several hundred dollars into the display
> modules alone. Good luck with your project.

Depends.  Jameco has certain modules available pretty cheap.  For example,
a 5x8 module (1.5"x2.4") with anode-column, cathode-row (if memory serves)
is $1.95 for one, $1.75ea for 25, $1.25ea for 100, and $0.99ea for 250.  A
40x5 sign would cost less than $10 for the LED's, and even a 64x15 sign
(19.2"x4.5") would only cost you about $44 (along with a spare module)

1997\05\15@013432 by Michael Coop

flavicon
face
part 0 1238 bytes
I haven't played assembler for about 10 years, so I just bought a PicStart-Plus kit to work on a project in hand - which requires large format animated alphanumeric displays (about 30 panels)

Just doing the preliminary number crunching, I came out with quite respectable results for the multiplexing -

256 columns (8 bits per column)
CPU clock @ 4MHz
100Hz refresh rate

Provides enough time for almost 40 (16Cxx) instructions per column scanned.

If the comms is handled inbetween scans, the interruption should be minimal for most applications.
Say 9600bps / message is 256bytes (close enough), then the comms should happen in about 0.3s

Although I concede that cranking the clock up to 10MHz provides a lot more room for animation etc, where bit patterns need to be processed on the fly for all columns in each scan (updating the contents of the display more than 25 times/sec is pointless, as the viewer will never see it), so there is more time available than appears - if I'm not wrong ???

I think that's what I wanted to say...

Anyway, if anyone feels like sharing some of their source code - feel free... :)


Michael Coop
Tel:    +60 3 411-6900
Fax:    +60 3 411-8260
Mobile: +60 12 206-1116
email   .....mcoopKILLspamspam.....pop.jaring.my


1997\05\17@123848 by DTU- No Proxi

flavicon
face
>For static images, the faster the better; for scrolling images, you want
>to scroll an integer number of pixels per frame [typically one] unless
>you're doing tricky fractional-dot techniques.

> After you've got all that stuff working right, then you can start
worrying
> about the higher-level issues of scrolling, flashing, blinking and the
> types of information you'll present. Note that you may have to modify
your
> display refresh algorithm depending on the kind of motion or effects
you're
> trying to achieve.

>Your last point is extremely important, though I think you need to
"worry"
>about the higher level issues before you design the circuit.  For
example,
{Quote hidden}

Hmmm, Interresting. I actully just made a LED panel and I'm having some
problems. When the picture is moving the dots seems to be double (is this
what you call "seams"). I fount out that I could remove this by setting
the
refresh rate down to once per frame. But then I get flickker due to the
low
refresh rate.
What can I do to prevent this when I change the refresh rate?
And how these special refresh algorithms working?
Can the problem be solved by double the display buffer, and how?

Thanks in advance

  Lars

----------------------------------------------
email: EraseMELJspam_OUTspamTakeThisOuTPOBoxes.com
----------------------------------------------

1997\05\17@132252 by John Payson

flavicon
face
> Hmmm, Interresting. I actully just made a LED panel and I'm having some
> problems. When the picture is moving the dots seems to be double (is this
> what you call "seams"). I fount out that I could remove this by setting
> the
> refresh rate down to once per frame. But then I get flickker due to the
> low
> refresh rate.
> What can I do to prevent this when I change the refresh rate?
> And how these special refresh algorithms working?
> Can the problem be solved by double the display buffer, and how?

I'd suggest that you--either in your imagination or in reality--place a
piece of acetate or other transparent material over the signboard and move
it right to left at the rate the dots will be moving.  Every time a dot
flashes, mark it on the acetate.  [obviously, doing this for real would
require the ability to step through the frames unless you've got a REALLY
fast hand with that Sharpie(r)].

If you do this with a display that's shown twice per, you will observe
that each dot will appear twice on the acetate; the second appearance will
be 1/2 dot to the right of the first.  There is no way to rid yourself of
this phenomenon other than by speeding up the scrolling, slowing down the
refresh, or both so as to be at a rate of one dot per frame.  If neither
of these options is acceptable, you can try instead to take advantage of
the phenomenon by doubling the width of your display buffer and showing
the even pixels on one flash and the odd ones on the other.  This will
allow you to double the perceived resolution of your display, and may help
to reduce the annoying double-dottiness of the scroll.

Additionally, if you are using discrete LED's you may improve the
appearance of *scrolling* text by staggering the LED's in alternate rows.
You then scan the rows in even/odd order, so that the flicker will be less
noticeable than on a straight scan.  Unfortunately, this will be a bit of
an annoying display layout for anything other than text which is scrolling
at the proper speed, but such is life.

1997\05\18@073154 by Leon Heller

flavicon
picon face
In message <199705171625.SAA11626spamspam_OUTnis.student.dtu.dk>, DTU- No Proxi
<@spam@ljKILLspamspamPOBOXES.COM> writes
>Hmmm, Interresting. I actully just made a LED panel and I'm having some
>problems. When the picture is moving the dots seems to be double (is this
>what you call "seams"). I fount out that I could remove this by setting
>the
>refresh rate down to once per frame. But then I get flickker due to the
>low
>refresh rate.
>What can I do to prevent this when I change the refresh rate?
>And how these special refresh algorithms working?
>Can the problem be solved by double the display buffer, and how?

The double dots sound like "temporal aliasing", similar to the effect
you get when you move a mouse rapidly - you see several copies of the
pointer. It's caused by the persistence of vision.

Leon
--
Leon Heller
Amateur radio callsign: G1HSM
Email: KILLspamleonKILLspamspamlfheller.demon.co.uk http://www.lfheller.demon.co.uk
Tel: +44 (0) 118 947 1424 (home) +44 (0) 1344 385556 (work)

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...