Here are some of my experiences when I was first developing Dasher S:
When I first got the idea to serially control a display I started at the maximum speed (or so I thought) the micro controller chips I used would handle - 9600 baud. At that time I had only one control box with 8 channels. I ran some patterns on a "fake" Christmas tree I had out in the yard (a tree made with a center support and 8 vertical sets of lights coming down from the top of the support at an angle). 9600 baud worked well. I then made a second control box and did more testing. Each time communication was necessary I sent out all information to both boxes. I started noticing that there was a delay between when box #1 would react and when box #2 would react. They weren't the same even though they should've been. At the same time I noticed that the computer screen was slow to redraw/refresh. Keep in mind that I was really pushing things to see just how fast I could send information out. I discovered that if I minimized my program so that Windows wouldn't have to redraw/refresh the screen, the boxes started updating at the same time. When I would bring the program back onto the screen the problem would re-appear. This is why there is an option to turn off the screen redraw/refresh in Dasher today.
Once I got past that problem things were great and I fully developed the protocol or communication scheme the computer would use to would talk to the control boxes. That's when I realized I could have up to 106 control boxes available to Dasher.
One day I got to thinking about having 106 control boxes and the large amount of information that Dasher would need to send out for each column in the grid. Remember, for each column Dasher would send out all information to all control boxes. So I did a test. I changed the address on control box #2 to address #106. I then tested the communication to see if there would be a delay between when control boxes #1 and #106 reacted to commands in the same column. Sure enough, there was a noticeable delay. Not a good thing. About this time I had learned that I could raise the baud rate to 19.2K baud. Thinking this would solve my problem I gave it a try. The delay did almost disappear but I still wasn't happy with it.
A few days later I got to thinking about how DMX dimmer packs would retain their settings even when unplugged from the data line. As I compared that to what I knew about my control boxes I realized the same was true for my control boxes. I tested this and sure enough, when the data cable was unplugged the boxes would retain the state of the channels (either on or off). I got to thinking about this and realized that if the boxes would retain their settings that Dasher wouldn't need to update them each time a new column occurred unless they needed updating.
So I optimized the code that Dasher uses to send information out. It looks to see if there are any changes in a control box from one column to the next. If there aren't any changes then it doesn't send information out to that control box, thus freeing the data line up for other control boxes that do need updating. Once I got the code working correctly (a MAJOR task and pain) I again tested control boxes #1 and #106 with control boxes #2-#105 not needing any updating. This time the control boxes both reacted instantly. Problem solved.
I have incorporated this "only send out changes" logic in each version of Dasher. It makes for more efficient communication and, as a result, much faster changes in the control boxes.
Last updated September 18, 2001