Repairing a DMX Lighting Controller

While home for Christmas, a relative handed me a DMX lighting controller, stating it had quit working properly.  I was free to do with it as I please, however I wanted to get it working again if possible.

Although I had a rough concept of how a DMX system works, I knew nothing of the actual protocol.  Off to wikipedia, where I found out DMX is actually DMX512, with the physical layer adhering to the EIA-485 (RS-485) standard.  For those that don't know, RS-485 is a commonly used long distance industrial serial communication standard, utilizing differential signaling for good noise rejection.  For me, this was good news as I had parts on order for another project that will utilize RS485 and therefore had a way to interface with this board.

The controller in this case is a Chauvet Obey 8, which can command 4 fixtures up to 8 channels each. (32 DMX channels)  It was not clear what the problem was, but based on conversations, it could be bad power delivery, RS485 driver, or complete failure of the main microcontroller.  First step was to crack this thing open and get an idea of what I was working with.

The board was simple, built with through-hole components, easy to identify.  Aside from LEDs, push-buttons, and linear potentiometers, I was able to identify a couple of multiplexers, a RS485 driver, an op-amp, external eeprom, and, to my delight, what appears to be an Atmel ATmega mcu running the whole show.  I could not confirm exact model, because it had be scratched off by the manufacturer. (I'm guessing ATmega8 from looking at the board.)

I started my investigation with a quick visual of the board and associated components.  Nothing appeared broken or burnt and there were no stray metal filings or wires to short out components.  Next I fired the board up to look for suspicious behavior. First check was the incoming power.  There was some play in the barrel plug, but the board could be powered up with it orientated in the correct position.
Second, I traced the power to the main board, verifying 12 volts into the 7805 power regulator and 5 volts out.  Both the incoming and outgoing power capacitors appear to be in good condition, with no bulging, which is a common failure among circuit boards.

Without a DMX slave device to verify output, I needed to improvise using an oscilloscope to search for the DMX output and see if it was doing anything.  (This would be the electronic equivalent of knowing someone was speaking French, but not understanding what they were saying.) I probed the MCU and the RS485 ICs until I found what looked like the proper DMX signature in logic level serial (0-5VDC). 

A quick check of Saleae's website indicated DMX512 support had been added to the list of protocols my analyzer can decode. Now the logic analyzer is limited to +5V signals, but thanks to the oscilloscope, I knew which pins were safe to connect to.  With probes hooked up, I fired up the analyzer program and pulled a quick sample.

As shown above, the signal was characteristic of DMX with a long BREAK pulse, followed by a start Byte, then 32 "channel" bytes.  Shown below, I zoomed in on channels 1-8.  Most values are 0, but values other than 0 can be seen on channels 1 and 4.

Zooming in on Channel 1, the value is shown as 217.  With the 7 channel RGB lights typically used with this controller, that would translate to the Red color being nearly full ON.

Moving over to Channel 4, the value is shown as 132, which would trigger one of the pre-programmed macros in the RGB light.

With the logic level DMX signal verified, I decided to replace the questionable power jack and reassemble the unit before testing the RS485 level DMX signal.  While soldering in the new barrel jack, I noticed broken solder joints when pressure was applied to the XLR jack.

With the solder joints fixed and the both boards re-installed, the output jack was connected to a RS485 receiver to convert the output back to logic level, readable by the logic analyzer.

A quick re-run of the analyzer verified proper output with no noise or broken signals, indicating the controller was again fully operational.

Logic Analyzer Decoding PPM and TTL Serial

In my spare time I have been teaching myself to program microcontrollers, specifically Atmel ATMega328s & ATTiny85s using the Arduino IDE.  It has been fun learning what can be done with a few lines of code and a handful of $3 ICs.  As a result, it has become necessary to better understand how devices communicate and one of the best ways to do so is with a logic analyzer.  I recently purchased a Saleae Logic 8-channel logic analyzer and went to work testing anything I had lying around.

First up was my Futaba 4 channel RC transmitter. (See this post about converting a Futaba 4 channel radio to 5 channels.)  For those who are unfamiliar with hobby grade radio control equipment, they typically use pulse-position modulation to encode stick inputs and pass the information to the servos.  The transmitter reads the position of all the inputs and encodes this information as a single pulse train as shown below.

To decode this pulse train you have to understand that RC servos are fed a pulse-width modulated signal at 50 hz. Pulse length represents position and varies from 1ms to 2ms with 1.5ms being the neutral position in most cases.  Looking at the pulse train above you can see the signal is held HIGH and the pulled LOW for a brief period. If you measure the time between the falling edges, you will see that it is about 1.50ms and the pattern repeats 5 times.  This is the position of the 5 channels encoded as a series of pulses.  Pretty cool huh?  It should be noted that Futaba uses inverted logic and other radio systems may use a signal that starts LOW and is driven HIGH.


After looking the transmitter's output, I wired the logic analyzer to the receiver and recorded another sample set.

The job of the receiver is demultiplex the PPM signal into the individual servo signals as shown above.  Channels 1-5 show how a PPM signal is usually decoded.  On the first falling edge of the PPM signal, the output for channel 1 goes HIGH, on the next falling edge of the PPM signal, the output for channel 1 goes LOW and the output for channel 2 goes HIGH and the pattern repeats until all 5 channels are decoded, at which time there is a long pause that tells the receiver to start over at channel 1 on the next falling edge.

This is where things stopped making sense.  My 4 (now 5) channel radio came with a 7 channel receiver.  Looking at the 6th channel, it can be seen that it outputs a pulse that goes LOW at the beginning of the PPM train and then HIGH again at the end.  This isn't useful for driving a servo, so I'm not sure if it was ever meant to serve a function.  Channel 7 mimics Channel 1 and Channel 8 does nothing, which confirms that it is simply a battery input.


Next I wanted to test the actual logic analyzing functions of the software.  I wired a graphic LCD to an Arduino and loaded a sample sketch that reads data from the serial UART and displays it on the screen.

Typing a simple "Hello World" in the serial monitor window, I hit enter, sending the information to the Arduino and the logic analyzer.

I added an 8N1, 9600 baud analyzer to Channel 0 and, as seen above, it decoded my "Hello World" comment also showing the 'n/' newline escape sequence at the end of the string.

So far I'm impressed at how easy this unit has been to operate and hope to put it to use in the future.