I have a product! It’s an arduino microcontroller that receives a DMX signal and does things with it!

What it does well:

• Successfully receives a DMX signal
• Interprets the data sent by the signal
• Acts on the data: for my sample implementation, channel 1 dims a red LED, channel 2 triggers a green LED on/off, and channel 3 triggers a blue LED on/off

Known issues with it:

• I cannot yet receive all 512 channels in the protocol. I was unable to determine why; if I had to guess, I’d bet on it being something involving memory usage. I tested it up to 24 channels successfully.
• It cannot have two of the LED’s on dimming systems simultaneously. Something about the timers and interrupts in the language/hardware gets royally screwed.
• It occasionally fails on for a split second. That is, the signal coming in is saying “0%,” and for a brief moment the controller reads “100%? Alright!” from memory. It then resets to the correct value, but it’s quite annoying.

Honestly, this was not quite the result for which I had hoped. Surely I could have developed a more reliable program! After all, the data format is well-defined, and the algorithm I designed while planning this project accounted for everything within the data format.

That said, I’m pretty proud of what I’ve accomplished. First, I was able to get the correct set of ones and zeroes coming in at all. Not too shabby, considering there were 250,000 of them coming in every second. Additionally, I was able to match the pace of the signal format, correctly interpreting the beginning few data packets of every set of 512 that came in; again, not too bad, considering there were probably about thirty of those coming in every second.

On top of that, I did nearly all of this project in AVR assembly code, which is pretty damn cryptic. Here’s a section from my code:

 "Readbit:"                             "\n\t"
 "SBIC 0x09, 0x02"                      "\n\t" //1 
 "ADD r16, r17"                         "\n\t" //1
 "LSL r17"                              "\n\t" //1
 "BRCS Storebyte"                       "\n\t" //1f2t
 "nop\n\t""nop\n\t""nop\n\t""nop\n\t"          //4
 "nop\n\t""nop\n\t""nop\n\t""nop\n\t"          //4
 "nop\n\t""nop\n\t"                            //2
 "CALL Delay48"                         "\n\t" //48
 "RJMP Readbit"                         "\n\t" //2

The above code was part of my method to read in a byte of data. Imagine a whole lot of that (albeit with more comments reminding myself of what each line was doing) and you basically have my project.

Overall, I’m pretty pleased with what I was able to learn from this project. No, it wasn’t the product I wanted, but I now know a ton about how to program in the Arduino environment and in AVR assembly language. I also know exactly how a DMX512 signal operates. In all, not a bad take-away for my time this summer.

Plus, I still have 400 transistors in a desk drawer next to me. So if you need any transistors… just let me know.

This project has reaffirmed for me the fact that I am a complete control freak. But this time, it’s out of necessity. Basically, I’ve resigned myself to doing this project mostly with assembler code.

For those who are unfamiliar with assembler, or coding in general, I’ll give a little overview. The Arduino environment works on a C-based language. C is a relatively low-level language compared to something like Java, Python, PHP, and many more modern languages. It works mostly with the basic functions a computer has; that is, the ability to load and store variables, manipulate them mathematically, and modify the flow of these with conditional statements (if this, then  that; else, that other thing). C requires at least a little knowledge of how the computer modifies each of these, but the programmer doesn’t need to know every specific. To run a C program, the programmer uses a compiler to change the C code into machine language. Machine language is the sequence of individual instructions for the computer to do that translate directly to the hardware inside; it’s all the ones and zeroes telling the computer what to do. The compiler is a powerful tool, as it automatically adds in a lot of instructions to make the program run well, without the programmer having to specify them. But in a project like mine, where timing needs to be exact, I’ve decided to make use of assembler language, which is basically a way to put in the exact machine language.

Difficulty aside, I’ve had success with this approach. I’ve been able to receive the DMX data with the Arduino and print it back to my computer screen. I’m happy to say, I’m getting the right data format. That was a major victory.

The next step is to try and make the computer only store the data that’s the actual data from the DMX signal, instead of every single one and zero that gets sent. We’ll see how that goes.

At this point, my materials have arrived, and I’m well on my way into working with the Arduino microcontroller and attempting to receive a theatrical DMX512 signal with it. And I’ve learned a few things.

• Transistors are really, REALLY cheap. And it’s really tempting to buy 400 of them for about $8. Additionally, I will never use all of the 400 transistors I bought.
• Shell out the money for the hardware that has documentation, because it’s really nice to know what you’re working with.
• Soldering irons get EXTREMELY hot.

So far, I’ve bounced around different areas of the project. Some days I’ll work with the code of the Arduino, and do things almost completely digitally. Some days I’ll work on my skills in making analog circuits. When I start calling damnation upon electronics in one area, I generally switch to the other.

I ended up buying the official standard for the DMX signaling protocol from ANSI, and that has been extremely helpful. It’s a bit dry, but it’s the finest reference I could ask for. Well worth the $40 I paid to download the PDF.

I am stymied in my attempts to correctly receive the stream of bits from the DMX signal. I have no doubt about my ability to interpret the bit stream once I receive it (I will likely eat those words), but getting the Arduino to get the correct values is proving difficult. What makes this more difficult is that I have no idea what the correct values should be, except for what I know of the format from the DMX standard’s specifications.

So now I keep tinkering, hopefully getting closer to an understanding of the solution to the problem.