Content-type: text/html Set-Cookie: cookiehash=D8TIX1F9GET8DML97LCWDC1UDL31CF7Q; expires=Thu, 22 Oct 2020 00:00:00 GMT; path=/; DMI News

DMI News

Previous Entry.. Next Entry..

Marquee Sign Progress

October 08, 2010 10:14

For those who are unaware, I am working on building a marquee sign. This is actually a very old project, one I started 10 years ago. For various reasons I've finally had the opportunity to resume my efforts on it and as of this moment, I have a functional working demonstration (although the entire sign will still take a few more days to complete). I will highlight the trials and tribulations of this event.

To get down to basics, a marquee sign is an enlongated LED array, which typically is used to scroll messages, although it can be used for pretty much any display purpose that it's physically capable of. When I first attempted this project, I was uncertain how to proceed. My first inclination was to use D-flipflops so each LED represented one bit of memory and I would clock the flipflops to automatically scroll the data across the board. While workable, it would also be very expensive, consume a lot of power, and be very time consuming to construct. It would also prevent me from doing any sign other than one that scrolled from right to left. I quickly realized this wasn't a workable solution and instead planned out a design to simply refresh the LEDs one column at a time, and let persistance of vision do the rest.

My initial efforts at this refreshing met with some obstacles, which I ended up having to deal with recently as well. The parallel port puts out a 5V signal which is sufficient (plenty more so actually) to drive a LED. The 8 data lines on the port, as well as the control lines all put out the same voltage, however, since historically the control lines were bidirectional, whereas the data lines were output only, the impedance of the control lines is slightly different. Long story short, while I was attempting to feed one of the control lines directly into the shift register, it would result in extra clock pulses, or other junk signals, which at best was causing flickering in the LEDs that were supposed to be off, and at worst would cause LEDs to light up out of sequence. Adding 470 ohm resistors between the TTL circuits and the parallel port lines solved this problem and now the signals are received properly and the sign displays exactly as it should.

Even after I complete the sign, this is still going to be a work in progress. To update the sign without any noticiable flicker, I need to make it ripple (refresh the entire sign) at least 120 times per second. My benchmarking shows that the optimal solution requires around 30000 clock pulses per second. The computer has no problem with that speed, but usleep only has a resolution of at best about 1ms (or 10ms on older linux kernels). It can't get a finer resolution than the clock timer rate, which is supposed to be 1000hz on later kernels. One possible solution would be to increase this rate to about double the needed clock rate, to ensure that the pulses could be issued in a timely manner. This will require a kernel rebuild and compile, so I haven't messed with that yet. The current solution is to simply run a for loop for so many cycles just to chew up CPU time. On an otherwise idle computer, this works fine, but obviously it would cause problems if I had other programs I wanted to run on the same system, or if my sign control program is multithreaded. Another possible solution would be to add a crystal or even a capacitor based occilator to the sign circuit to feed an interrupt to the parallel port each time I want the clock to update. If I use the parport driver (or write my own), I can capture the interrupt and use that as a trigger to issue the pulse. If things act as they're supposed to, the interrupt (no matter how often it triggers) should wake up the sign process, let me issue the pulse and output the new port data, and then let me block the process, so that it won't use up any more CPU than necessary. I could have a full load of programs runnign on the system and as long as the sign process has enough priority, it should update flawlessly. I will work on this as a future extension to this project.

Once the sign is finished, I will mount it on the back wall and it will display the messages sent from the webpage (properly moderated of course). I may also provide additional programmable controls, so people can manipulate how the messages are displayed, or display bitmaps.

Images of the progress are here.