>JeffScholz wrote:
>>
>> Greetings,
>>         I am building a moving message display. It is 7 rows x 80 columns.
>> Multiplexing will be accomplished by loading shift registers with column
>> data and the powering sequential rows for 1.64mS each. Therefore, each row
>> will be refreshed once every 11.5mS.
>>         Is the refresh rate frequent enough to eliminate flicker? Can I
>> refresh at a slower rate? I sure could use the extra time for other tasks,
>> but I don't want a flickery display!!
>>
>> Thanks!                      Jeff
>
>I built an LED Moving message board around 1989 driven with a Z80 and
>used 74LS164s as shift registers. The timing was set to 2ms per row by 7
>rows which worked out at 14ms per cycle.
>
>The speed of the Micro has a lot to do with the timing. Several 'sweet
>spots' can be found to achieve persistance of vision with LED displays.
>
>I was using a 555 timer driven interrupt to set the row scan update, so
>I was able to easily select these 'sweet spots' by varying the interrupt
>timing.
>
>You load up your registers, switch the row on, go do some housekeeping
>such as getting new data and mapping it to your ram mirror of the
>display, then go switch the current row off, load the next, and so on.
>
>Don McKenzie  donKILLspamdontronics.com   http://www.dontronics.com
>
>SLI, the serial LCD that auto detects baud rates from 100 to 125K bps.
>SimmStick(tm) A PIC proto PCB the size of a 30 pin Simm Memory Module.
>Covers all versions of the PIC16cxx family plus the Atmel AT89C2051.
>

>>25 hz.
>
>Its interlaced though isn't it so a different picture each 25th of a second not
>a different picture each 50th of a second - eh ?
>
>So its 25Hz isnt it...
>
>Rgds
>
>Mike
>

>>
>>Tim
>
>All TV's flicker.
>
>Some people notice this flicker - others do not. Depends on a whole range of
>factors. I believe every persons brain has a built in clock rate of around
>20 to 40 cycles per second. There is a basic minimum response time which
>is considered to be a certain multiple of the human clock rate. Thats one
>reason that sprinters (in the olympics) are considered to have a false
>start if there response rate is less than 75mS AFTER the gun !
>
>There seems to be some correlation between metabolic rate and a persons
>likelihood to notice flicker. My girlfriend was diagnosed with a thyroid
>condition that has kept her metabolic rate slow for years - since she
>has been on medication she notices flicker on some SVGA monitors where she
>would'nt notice it before...
>
>Personally I can't stand anything below about 60Hz on a SVGA but put up with
>a TV at 25 since its a smallish screen and the intensity is downand I think
>the phosphor persistence is a bit longer ?
>
>Rgds
>
>Mike
>

>>
>> Greetings,
>>         I am building a moving message display. It is 7 rows x 80 columns.
>> Multiplexing will be accomplished by loading shift registers with column
>> data and the powering sequential rows for 1.64mS each. Therefore, each row
>> will be refreshed once every 11.5mS.
>
>Would you mind telling us how you're going to sink the current for each
>row? even at a nominal 20ma per LED you can have a max sink current of
>1.6A per row. That's a whole bunch of current!
>
>Oh and the perceived brightness is more a function of peak current through
>the LED rather than average brightness. So typically an LED pulsed at
>100ma at a low duty cycle will have a higher perceied brightness than a
>20ma at a higher duty cycle.
>
>That's why I usually drive columns instead of rows at a much higher frequency.
>Using drivers like the Allegro UCN5801 sink driver at a peak 500ma per, each
>LED can be pulsed at 70ma each. And with loading taking only 10us or so at
>20 Mhz on a pic (Read column, write to latch, shift column driver) it leaves
>almost 600 uS between columns to do other stuff. Works great interrupt driven.
>
>>>         Is the refresh rate frequent enough to eliminate flicker?
>
>86 Hz? probably not. May work if you can get the LED's bright enough. Do
>you have a 5-8A sink for each row available (60-100ma current per LED)?
>
>>Can I refresh at a slower rate? I sure could use the extra time for other

>
>This is easily determined by testint. Just wire up one 5x7 display and vary
>the refresh rate. It becomes very apparent when flicker occurs.
>
>BTW how did you pick your display numbers above?
>
>Your best bet is to pump up the current and drop the duty cycle, the
>perceived brightness will go up and you'll get some of the persistence effect
>from the user's eye meaning that you can go longer before flicker is perceived.
>
>BAJ
>

>Greetings,
>        I am building a moving message display. It is 7 rows x 80 columns.
>Multiplexing will be accomplished by loading shift registers with column
>data and the powering sequential rows for 1.64mS each. Therefore, each row
>will be refreshed once every 11.5mS.
>        Is the refresh rate frequent enough to eliminate flicker? Can I
>refresh at a slower rate? I sure could use the extra time for other tasks,
>but I don't want a flickery display!!
>
>Thanks!                      Jeff
>
>

> From: Pedro Barrios <RemoveMEbarriosKILLspamNANOFAB.TAMU.EDU>
> To: PICLISTSTOPspamspam_OUTMITVMA.MIT.EDU
> Subject: 32 bit rotate
> Date: Tuesday, June 09, 1998 2:59 PM
>
> Hi everyone,
>
> I'm trying to find a way of displaying a message in a 5x7 LED
> array. Basically, I don't have a good idea of how this is
> usually done, but since I have worked a little bit with the
> 16C84, I thought I give it a try.
>
> I was thinking about having a message array 32 bits long by
> 5 bit wide containing the information I want to display. I would
> then take each one of the 32 bit words and rotate sequentially
> bit by bit and display the 7 most significant bits after each
> rotation. I would do this for each of the 5 rows of the LED display.
>
> I will appreciate any help on how I do this 32 bit rotation with
> the PIC, and also any suggestions or comments as of how messages
> can be displayed in LED display arrays with the PIC.
>
>
> Best Regards,
>
> Pedro

>
>Data is received over a single pin serial line and
>transmitted over a second single pin serial line. This
>allows me to connect the "output" of one PIC driver module to the
>"input" of the next. Currently I use a portable PC to
>input the data to the first (rightmost) Pic driver module.
>
>Input data is received as 8 bit data and stored in a
>file register. Every time new data comes in, the data
>is "bumped" or moved to the file register to the "left".
>When data is bumped out of the "leftmost" register,
>I send it in serial format to the PIC module to the
>left of the current pic module. I use a single system
>clock that drives all the PIC modules.
>
>Modules can be added pretty much indefinitely as long
>as you buffer the clock occassionally.
>
>Instead of using standard serial UART routines, I used a
>self-clocking scheme that allows a large range of
>baud rates. The PC communicates in serial mode, but using
>a bit from the PCs parallel port. My reason was simply
>so that I could control the self-clocking. One bit
>of the parallel port was used as an input. This allowed
>me to send clocking and other handshake info to the PC so it
>could operate at maximum speed.
>
>The PC would output serial data in self-clocking fashion
>to the rightmost PIC. The MSB of the 8 bit data was used to
>indicate that control rather than data was being sent.
>This allowed me to send instructions such as Clear All LEDs
>to the entire string of PIC modules. Each PIC would
>simply relay these commands when they received them.
>I wrote up a program in Foxpro that allows me to create
>custom characters up to 7x8. This program then created
>a memory map that allows me to decode any ascii character
>to its visual components. To make the display capable of
>handling more characters I use the MSB to indicate when
>a character is finished. I usually include one blank
>column as a separator for characters. Thus a character
>like "i" will occupy less width than the character "W".
>In other words, the technique allows proportional fonts.
>
>I prepare the text that I want displayed in a text file.
>Then I run the PC program that loads the desired font
>set, decodes the characters, and sends the column data
>to the first PIC. Scrolling speed is software adjustable,
>and provision is made to use multiple font sets within a
>single message. Once a message is completely sent I send
>out a string of spaces and send the message out again and
>again.
>
>This all works fairly well, is easy to understand and
>implement on a 16C84, and has a reasonable parts count.
>The biggest expense is all the LEDs. If you use the newer
>super-bright LEDs you will pay more, but you can move the
>LEDs further apart and get a really large display that
>is visible for reasonable distances.
>
>Hope this helps.
>Fr. Tom McGahee
>
>----------
>> From: Pedro Barrios <KILLspambarriosspamBeGoneNANOFAB.TAMU.EDU>
>> To: EraseMEPICLISTEraseMEMITVMA.MIT.EDU
>> Subject: 32 bit rotate
>> Date: Tuesday, June 09, 1998 2:59 PM
>>
>> Hi everyone,
>>
>> I'm trying to find a way of displaying a message in a 5x7 LED
>> array. Basically, I don't have a good idea of how this is
>> usually done, but since I have worked a little bit with the
>> 16C84, I thought I give it a try.
>>
>> I was thinking about having a message array 32 bits long by
>> 5 bit wide containing the information I want to display. I would
>> then take each one of the 32 bit words and rotate sequentially
>> bit by bit and display the 7 most significant bits after each
>> rotation. I would do this for each of the 5 rows of the LED display.
>>
>> I will appreciate any help on how I do this 32 bit rotation with
>> the PIC, and also any suggestions or comments as of how messages
>> can be displayed in LED display arrays with the PIC.
>>
>>
>> Best Regards,
>>
>> Pedro
>

>I used Excel to map the characters by putting '1' on the
>cells and making the column width smaller so it may look
>like a 5x7 char.  Custom chars are easily made this way
>and no other programming is needed only by just making the
>right formula.
>
>
>Rgds,
>Reggie
>