Every year, I team up with raider.no to arrange a party in Hurdalen, or around the Oslo area. And one of the things that is important for us (especially me and William), is to create a cool opening show, using our own innovative technology. We don’t have a lot of money in the organization, so we tend to also develop stuff that already exists.

This year, we wanted to do the timing of the show entirely in our own system, as we weren’t satisfied with the Avolites Pearl systems own “show timing” system.

So we split up the task in two daemons and a GUI. The two daemons are written in C, and the GUI in Perl (using the Catalyst Framework).
The first deamon is the “DMX daemon”, which handles existing DMX data from the Pearl mixer as the rest of the night will be run from this board. This is transferred via network over the ArtNet protocol. It also listens for our own udp DMX-commands, which includes simple operations like, fade (linear), blink, subtract, add, etc. These functions allows external scripts and programs to send simple commands to control the lights. For example “fade channel 1 from 0 to 255 in 2 seconds”. Which would then automatically execute, without the client having do anything more. You can also group together a bunch of actions in a “transaction”, and then have it execute as soon as you send the “end transaction” command. The resulting DMX data is sent to the Enttec DMX dongle connected to this computer. The system is so lightweight, that there was no noticeable delay from using ArtNet->DMXDaemon->EnttecDongle over network, than using the direct DMX output from the board. The nice thing is that, if we want, the show daemon can forcibly stop all data from the Pearl mixer, or even alter the data using add/subtract/max/min commands.

The next daemon is the show daemon, this takes complete scripted shows from the database (created by the GUI), and converts them to commands to be sent to the DMX daemon. This daemon uses (lib)jackd2 to fire events at the exact time according to the sound file playing in a external program like Ardour, which sends timecodes via jackd. The show daemon has functions to group together effects that will be executed at specific timestamps.

Here’s a link to a overview of how we wired it all up for the show.

The whole system is kept open-source at github.

So, in the last blog entry I told you about the perl DMX backend that we are doing for the party project of ours.

We have concluded that we will have a bitchin’ intro show. And it will be timecode controlled. Every little audio / DMX / Video effect will be timed to the millisecond.

To do this, we have (for now) concluded that we will use Ardour as the audio platform, and use jackd as the timecode server.

The nice part about this, is that it’s very easy to code a jack client that fetches the timecode in realtime, and then transmit it via UDP to our external timecode display. And thats where this blog post comes in place; we are creating a cool 8 digit 7-segment display to display our timecode.

William got 8 of these modules from Kay, who agian bought them for almost nothing at eBay. :D (in Norway they cost about $25 each at the time of writing)

Anyways. As you see in the picture, william has glued the 8 digits together, wich we will put inside a box, and wire up with some pic18f4520 and some ENC28J60 for ethernet connectivity. Yes, the module will be stand-alone, only connected to ethernet, and display the current timestamp/timecode in Ardour/our DMX system.

Do we _really_ need it? no. Is it really cool? yes.

So, so far we have finally gotten the box for the device. It’s acctually a image frame, with an exceptionally deep frame on the backside to contain the whole shebang.

Here are some more “under construction” photos:

In the first photo you can (almost) see the PIC18F4520 on a vero board, with a connected prototype board with the ENC28J60 chip, which works perfectly and successfully outputs data to the (soon to be connected) displays when it receives timecode UDP data on port 1337 ;P

This project has not been the easiest, even though the concept is simple. I’m not the greatest engineer in regards to analog electronics. The problem is that the 7segment displays needs 7.2v, and uses common anode. This means that I cannot use the displays directly from the PIC processor. So i went on using a ULN2803A to drive the display. This solves the “common anode” problem. Now on to solving the 7.2v problem. I have as I said, not very much to say in the analog electronics world. So I went on, and found the first PNP transistor I could find. Kay was kind enough to donate them to us.

He had a bunch of 2N3906 transistors, wich seemed to be “workable”. So i set them up on a breadboard and after some fidling with resistors and pulling up the signal, to let the PIC pull it down, to enable the flow trough collector and emitter. This seemed to work great, so I soldered the whole shebang together.

Everything works great now, except that the display “fluctuates”. Seems like either the 5v regulator is too weak (it gets pretty hot, but I can’t check it, because my multimeter doesn’t want to measure current), or the transistors are a bit too sensitive. Sometimes, when there is traffic on the network the display fluctuates when the ethernet-leds light up. So something is not at it’s fully potential yet. But I’ll measure a bit when I get a working multimeter.

So here are the latest images(only thing missing is the 4 dots at the bottom):