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.
